Skip to main content

v2.73.1

Binaries and the merged-pull-request list are on the GitHub releases page.

This release is the second milestone (PD2) of the documentation epic that re-frames orun as platform discipline as code. It covers pillar 1, declare: your platform's structure and standards written as intent. The binary is unchanged from v2.73.0.

A page for every standard, and what orun does with it​

The new standards page lists every standard a platform team can declare, by the question it answers: what a component must look like, which version of a golden path, how it may run in each lane, in what order, with which secrets, and within what blast radius. Each one is labelled enforced (a command fails), recorded (in the plan or catalog as evidence), or declared only.

Writing it surfaced several claims the docs made that the code does not back, now corrected across the site:

  • Group, environment, and execution-profile policies were described as enforced at compile time. orun carries them onto every component instance but does not act on them yet.
  • Cross-plan promotion gates were described as checks that require prior success. They are recorded on the plan, not enforced.
  • .orun/compositions.lock.yaml was described as pinning composition sources; v2.73.0's landing page, principles, and README repeated it. orun writes the lock but never reads it. The pin that orun plan enforces is a digest: on the source in intent.yaml, and every plan records the digest each source resolved to.
  • A deprecated composition was said to print a warning. Its lifecycle is recorded on its catalog entity; no warning is printed.
  • condition on a component's dependsOn is declared only; an enforced edge always waits for success.

Rewritten​

  • Intent model is the pillar's hub: who declares what, every intent.yaml section, component.yaml, the merge model, and what reads intent. Its examples now pass orun validate.
  • Compositions is "a golden path written as code": the four documents and how each is enforced.
  • Trigger bindings, profile rules, dependency rules, environment promotion, secrets, runtime environment, and the composition reference pages open with why each matters as a standard.

Fixed​

  • Job IDs are written as component.environment.job everywhere, matching what the planner emits; the component@environment.job form is legacy.
  • The how orun works and resource-model examples no longer wrap intent fields in spec:, and promotion.dependsOn uses {environment: …} objects.
  • The resource model explains the three API groups (sourceplane.io, orun.io, orun.dev).
  • orun validate is described accurately: it checks the intent, discovered manifests, the reserved ORUN_ prefix, and profile and dependency rules; schemas are checked by orun plan.