v2 release

Status: Withdrawn · Audience: Operator · Area: L — Release & distribution

---

Withdrawn. This feature described the release that opened v2. There are no epochs any more: everything that was sequenced behind 2.0.0 now sequences towards 1.0.0 on one train, and there is no second epoch for a release to open. Its requirements are locked by no version and gate nothing.

What it was actually about — that a major ships no stubs — survives in OPS-R54, which now says it without epoch vocabulary and says it of every version rather than only of a major. The text below is kept as written, because a withdrawn feature that is deleted leaves a reader of the history with a citation and nothing to read.

Purpose

Ship the ecosystem to the same bar the product was shipped at. 2.0.0 finishes v2 the way L1 finishes v1: not a summary of the minors that delivered the ecosystem features, but the release of that surface — distributed, verified, and upgradable, through the one pipeline that already exists rather than a second one built alongside it.

Behaviour

One pipeline, not two

The v2 features MUST ship through the same signed, multi-platform pipeline as v1 (L1) — the same artifacts, signatures, tap, and installers — rather than a separate distribution path. A second pipeline is a second thing to keep honest; there is one.

The same bar, applied to the ecosystem

Every v2 feature MUST be installable and runnable on macOS, Linux, and Windows to the same standard v1 was held to: run-tested on each platform, not merely compiled, and documented on the site generated from this specification.

A tested upgrade, not a reinstall

An operator on a v1 release MUST be able to upgrade to 2.0.0 without losing what they configured. The upgrade MUST be tested and MUST preserve the operator’s configuration and data, so moving to the ecosystem is a step forward rather than a fresh start.

The no-stub bar it clears

2.0.0 finishes v2, and a major ships no stubs: it MUST NOT be cut while any feature it locks is not both Accepted and shipped. The bar is measured in features rather than in requirements taken one at a time (OPS-R54).

Edge cases

Situation	Expected behaviour
A v2 feature runs on two platforms but not the third	The release MUST be blocked until it runs on all three, not shipped as mostly working.
An upgrade from v1 would drop configuration or data	The upgrade MUST be corrected or blocked, never allowed to lose the operator’s state silently.
A feature 2.0.0 locks is Accepted but not yet built	2.0.0 MUST NOT ship; the no-stub bar is unmet.

Acceptance criteria

ID	Requirement
L2-R1	The v2 features MUST ship through the same signed, multi-platform pipeline as v1, not a separate distribution path.
L2-R2	Every v2 feature MUST be installed and run — not merely compiled — on macOS, Linux, and Windows before 2.0.0 ships.
L2-R3	The documentation site and the installers MUST cover the v2 features.
L2-R4	An upgrade from a v1 release to 2.0.0 MUST be tested and MUST preserve the operator’s configuration and data.
L2-R5	The release pipeline MUST be reachable non-interactively, with no manual step beyond authorisation required to cut the release.
L2-R6	2.0.0 MUST deliver the container-engine abstraction — running under Podman, and running natively without containers — and MUST NOT be cut before it does. A major opens a generation with the capability that justifies the number; the rest of it follows as minors.

Related

• L1 v1 release engineering — the pipeline this reuses rather than rebuilds
• OPS-R54 — no version ships a stub — the bar 2.0.0 must clear
• A5 Migration — the state an upgrade must preserve