---
type: Decision
title: "Decision 0022 — The release line is pre-1.0, managed by release-please"
description: "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."
status: stable
tags: [decision, release, versioning]
---

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

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.