Current scope amendment (2026-09-07): ADR-0152 / #1341 supersedes former train and ownership policy.
[beta.2.1] Generalize prerelease version semantics for Beta.2 patch releases
Part of #1320. Releases: beta.2.1 (first implementation slice; no separate publish).
Problem
The repository-owned version parser deliberately narrowed SemVer and rejects legal multi-identifier prereleases required by the approved patch train: 0.44.0-beta.2.1 .. 0.44.0-beta.2.3.
Owner
tools/lib/version.ts is the single version-semantics owner; all other consumers delegate.
Before
Single-identifier prerelease parsing (beta.2); consumers embed ad-hoc regex/assumptions.
Target
Standards-correct prerelease identifier semantics:
beta.2 -> ["beta", 2]
beta.2.1 -> ["beta", 2, 1]
beta.3 -> ["beta", 3]
Required precedence: beta.2 < beta.2.1 < beta.2.2 < beta.2.3 < beta.3 < 0.44.0 stable. Historic OE strings (0.43.3, 0.44.0-alpha.10, 0.44.0-beta.1) must keep parsing. Build metadata stays unsupported unless the release system needs it; document the intentionally unsupported surface explicitly.
Consumer audit (mandatory, not one regex)
At minimum: tools/lib/version.ts; tools/autoflow/release.ts; tools/autoflow/version-anchors.ts; tools/project-constants.ts; release evidence; release-state-machine; release truth; version anchors; stale-claims detection; tag generation; npm verifier; prepare/finalize logic; tests. Also verify PREVIOUS_PACKAGE_VERSION mechanics and the six version-anchor documents for .2.N strings.
Successor semantics
Separate patch-checkpoint successor (beta.2 -> beta.2.1 -> beta.2.2 -> beta.2.3) from public-stage successor (beta.2.3 -> 1.0.0-alpha.1). Do not overload one ambiguous function; names must express release intent.
Tests
Parsing/formatting/comparison/channel extraction/normalization/stale claims/release-state planning/prepare-finalize transitions/resume-after-failed-release. Required ordering cases: beta.1 < beta.2, beta.2 < beta.2.1, beta.2.1 < beta.2.2, beta.2.3 < beta.3, beta.3 < 0.44.0.
Release
beta.2.1. A release-prepare dry-run must prove the lane can target 0.44.0-beta.2.1 without breaking the Beta.2 prepare-repair consistency fixes (#1316).
Accepted scope clarification
Release selection must distinguish SemVer ordering from strategic stage succession. Historic 0.44 internal alpha IDs remain unpublished; 1.0.0-alpha.1 is a public prerelease on npm alpha. Audit planning, prepare/finalize, channel selection and stale-claim checks for this distinction. The old Beta.3 successor is retired; existing comparison tests may retain beta.3 as a legal SemVer example.
[beta.2.1] Generalize prerelease version semantics for Beta.2 patch releases
Part of #1320. Releases:
beta.2.1(first implementation slice; no separate publish).Problem
The repository-owned version parser deliberately narrowed SemVer and rejects legal multi-identifier prereleases required by the approved patch train:
0.44.0-beta.2.1..0.44.0-beta.2.3.Owner
tools/lib/version.tsis the single version-semantics owner; all other consumers delegate.Before
Single-identifier prerelease parsing (
beta.2); consumers embed ad-hoc regex/assumptions.Target
Standards-correct prerelease identifier semantics:
Required precedence:
beta.2 < beta.2.1 < beta.2.2 < beta.2.3 < beta.3 < 0.44.0 stable. Historic OE strings (0.43.3,0.44.0-alpha.10,0.44.0-beta.1) must keep parsing. Build metadata stays unsupported unless the release system needs it; document the intentionally unsupported surface explicitly.Consumer audit (mandatory, not one regex)
At minimum:
tools/lib/version.ts;tools/autoflow/release.ts;tools/autoflow/version-anchors.ts;tools/project-constants.ts; release evidence; release-state-machine; release truth; version anchors; stale-claims detection; tag generation; npm verifier; prepare/finalize logic; tests. Also verifyPREVIOUS_PACKAGE_VERSIONmechanics and the six version-anchor documents for.2.Nstrings.Successor semantics
Separate patch-checkpoint successor (
beta.2 -> beta.2.1 -> beta.2.2 -> beta.2.3) from public-stage successor (beta.2.3 -> 1.0.0-alpha.1). Do not overload one ambiguous function; names must express release intent.Tests
Parsing/formatting/comparison/channel extraction/normalization/stale claims/release-state planning/prepare-finalize transitions/resume-after-failed-release. Required ordering cases:
beta.1 < beta.2,beta.2 < beta.2.1,beta.2.1 < beta.2.2,beta.2.3 < beta.3,beta.3 < 0.44.0.Release
beta.2.1. A release-prepare dry-run must prove the lane can target0.44.0-beta.2.1without breaking the Beta.2 prepare-repair consistency fixes (#1316).Accepted scope clarification
Release selection must distinguish SemVer ordering from strategic stage succession. Historic 0.44 internal alpha IDs remain unpublished; 1.0.0-alpha.1 is a public prerelease on npm alpha. Audit planning, prepare/finalize, channel selection and stale-claim checks for this distinction. The old Beta.3 successor is retired; existing comparison tests may retain beta.3 as a legal SemVer example.