Part of the shim-identity epic #604 — Story F (major-version boundary). Filed from the 2026-07-10 plan review.
Gap
The version+ring model gates blast radius, not compatibility. Consumer-facing channels (<agent>/next, /ring0, /ring1, /stable) encode a repo's ring tier, not a semver major. Since #870, @vN pins are treated as drift, and immutable <agent>/vMAJOR.MINOR.PATCH tags exist only as rollback anchors that nothing pins to.
Consequence: a breaking (major) change to an agent, once promoted through the rings to stable, reaches every stable consumer with no opt-in gate. There is no @dev-lead/v1-stable vs @dev-lead/v2-stable separation, and nothing halts a major bump as it advances next → ring0 → ring1 → stable. The strategy accepts this implicitly rather than by decision.
Decision needed (pick one)
- Major-scoped channels — introduce per-agent major-scoped channel tags (e.g.
dev-lead/v2-stable) so a breaking release requires a deliberate consumer re-pin to opt in. Preserves "callers pin once" within a major; a major bump is the one sanctioned re-pin event. Cost: doubles channel count per agent; re-sync + drift tooling (ring-pins.sh, compliance-audit.sh, fleet_stub_drift.sh) must learn the vN- prefix.
- Promotion gate at the major bump — keep single channels, but the canary-rollout engine halts a release flagged as a major (breaking) at the
next → ring0 edge pending explicit human sign-off, instead of auto-advancing. Cheaper; needs a way to mark a release "major" (release note / label / tag metadata) and a gate in the promotion engine.
- Accept and document — keep the channel-only model; add an explicit note to
agentic-release-strategy.md that majors are not gated and consumers accept auto-flow to stable. No engineering.
Acceptance
- A decision is recorded in the release-strategy doc's decision log.
- If (1) or (2): the ring/drift tooling and the canary-rollout engine honor the chosen mechanism, with tests; a breaking change cannot silently reach
stable consumers.
- If (3): the accepted trade-off is documented where the channel model is defined.
Notes
Part of the shim-identity epic #604 — Story F (major-version boundary). Filed from the 2026-07-10 plan review.
Gap
The version+ring model gates blast radius, not compatibility. Consumer-facing channels (
<agent>/next,/ring0,/ring1,/stable) encode a repo's ring tier, not a semver major. Since #870,@vNpins are treated as drift, and immutable<agent>/vMAJOR.MINOR.PATCHtags exist only as rollback anchors that nothing pins to.Consequence: a breaking (major) change to an agent, once promoted through the rings to
stable, reaches everystableconsumer with no opt-in gate. There is no@dev-lead/v1-stablevs@dev-lead/v2-stableseparation, and nothing halts a major bump as it advancesnext → ring0 → ring1 → stable. The strategy accepts this implicitly rather than by decision.Decision needed (pick one)
dev-lead/v2-stable) so a breaking release requires a deliberate consumer re-pin to opt in. Preserves "callers pin once" within a major; a major bump is the one sanctioned re-pin event. Cost: doubles channel count per agent; re-sync + drift tooling (ring-pins.sh,compliance-audit.sh,fleet_stub_drift.sh) must learn thevN-prefix.next → ring0edge pending explicit human sign-off, instead of auto-advancing. Cheaper; needs a way to mark a release "major" (release note / label / tag metadata) and a gate in the promotion engine.agentic-release-strategy.mdthat majors are not gated and consumers accept auto-flow tostable. No engineering.Acceptance
stableconsumers.Notes
scripts/lib/ring-pins.sh,scripts/compliance-audit.sh, the canary-rollout engine (relocated to.githubper Epic: relocate the canary-rollout engine + bootstrap into .github (org tooling consolidation) #613),.github-private/scripts/cut-release.sh,.github-private/docs/initiatives/agentic-release-strategy.md.