Statuses

A release progresses through a defined lifecycle, from an initial draft to general availability. Its status records where it is, and the controls that apply tighten as it advances.

From draft to GA

A release starts as a draft while its scope is assembled and its readiness gates are still being satisfied. As blockers clear and gates pass, it becomes ready for approval; once approved and shipped, it reaches general availability (GA) — the released, official version. Each status is meaningful: it tells everyone whether a release is still being shaped, awaiting sign-off, or done.

A controlled state

Once a release is approved, it enters a controlled state. Like an approved requirement, a controlled release is frozen — the bundle it represents can’t be quietly altered. This is what lets the version mean something: when you point to release 2.1.0, it refers to a fixed, signed set of work, not a moving target.

Locked items

While a release is being finalized and after it’s controlled, the items it includes are locked against changes that would alter what’s shipping. If something genuinely needs to change, that happens deliberately through a new version rather than by editing approved work in place — preserving the integrity of what was already released.

Invalidation

If something a release depends on does change despite the controls — an upstream item is revised, a dependency shifts — the release surfaces that as an invalidation, flagging that its bundle may no longer be consistent. Rather than silently shipping stale content, the release tells you it needs another look, in the same spirit as suspect links elsewhere in the platform.

Toward approval

Reaching GA isn’t automatic — it runs through an explicit approval against the release’s evidence, covered next in Approving.