Planning a release

A release is a governed bundle of everything that ships together at a point in time. Planning one means defining what’s in scope, giving it a version, and assembling the evidence that it’s ready.

Naming and versioning

A release has a name and a version — for example 2.1.0 — that identifies exactly which iteration of the product it represents. The version is how the release is referenced everywhere else: in approvals, in documents, and in the record of what was shipped.

What a release bundles

A release pulls together the work across modules into one coherent package. That typically includes the requirements, architecture, tests, and risks in scope, along with the supporting artifacts that prove readiness:

• Baselines — frozen snapshots of the included work
• A test plan — the verification that applies to this release
• Documents — the controlled documents that accompany it
• Dependencies — the other projects or releases this one relies on

Because everything is bundled by reference to real records, a release isn’t a separate copy — it’s a defined view over the actual work, captured at release time.

Readiness gates

A release tracks its readiness through gates that check whether each part is in order — items baselined, risks mitigated, tests passed, documents complete, dependencies satisfied. Where something isn’t ready, it shows as a blocker, so you can see precisely what stands between the release and approval rather than discovering it at the gate.

Locking the scope

As work is brought into a release, it’s locked so it can’t drift out from under the release while it’s being finalized. This keeps the bundle stable: what you reviewed and what you approve are the same thing. How a release moves through its lifecycle is covered next in Statuses.