exocomp docs

Decision 0022 — The release line is pre-1.0, managed by release-please

Withdraw the v1.0 label: the acceptance bar stays met and gate-tested, but the release line begins at v0.1.0 and release-please owns later versions.

Decision#decision#release#versioningDownload Markdown

Status: accepted · 2026-10-15

Context

On 2026-08-22 the acceptance bar was declared met: the five end-to-end stories passed their gates (test/e2e/v1-acceptance-gate.sh, 6 passed, 0 failed, on real infra), and an annotated tag v1.0.0 was placed on ba4fb83. The result was written into docs/design/v1-acceptance.md; a later page rewrite (2026-08-24, ee097b2) dropped that section while keeping the bar it proved, and the page itself was pruned on 2026-10-15 with the other development-process pages. The gate script is the durable evidence, and it is still in the tree.

The tag was never pushed to any remote. Its only effect was the local build string: the Makefile derives the version from git describe --tags --always, so every local build reported v1.0.0-<n>-g<sha>.

Two things changed the picture. The project moves to an organization remote, and releases will be cut by release-please from conventional commits. And 1.0 is a commitment about external compatibility — a claim the internal acceptance bar does not by itself make.

Decision

Withdraw the v1.0 label. The release line is pre-1.0 and begins at v0.1.0, tagged on main. Release-please owns subsequent versions from a 0.x manifest.

The acceptance result is kept. The bar was met and its gate still runs; what is withdrawn is the release label, not the evidence. 1.0 becomes a deliberate future commitment rather than something passing the internal bar confers.

Consequences

  • Local and deployed builds report v0.1.0 / v0.1.0-<n>-g<sha> instead of v1.0.0-…. The v1.0.0 tag is deleted locally; it was never pushed, so there is nothing to remove on a remote.
  • release-please writes one changelog file, and this repository keeps CHANGELOG.md and docs/operations/CHANGELOG.md byte-identical. The mirror sync is part of the release-please setup, not an afterthought.
  • The M3 plan keeps "v1.0" as a milestone name and stays as history. The acceptance page gains a status note so a reader does not mistake the name for a shipped release.