Align release policy and operational documentation

This commit is contained in:
2026-09-28 01:13:09 +00:00
parent 299ebc21a9
commit 3d0093e1fd
7 changed files with 242 additions and 177 deletions

View File

@@ -1,7 +1,7 @@
# Single-Command Release Workflow and Gate Review
Status: accepted target; execution order and acceptance checks are defined in the
[implementation plan](implementation.md).
Status: implemented on 2026-09-28. The
[implementation plan](implementation.md) records the completed work and checks.
## Intent and baseline
@@ -15,14 +15,15 @@ The upstream reference is release policy v1.4 at
`d84a38ebab26f048cafbe59a2246700c35d29843`:
[standard release policy](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/release.md).
Today, `scripts/release-check.sh` performs local validation; the runbook separately
At the planning baseline, `scripts/release-check.sh` performed local validation; the runbook separately
records a candidate commit and executes shell blocks for guards, branch push,
annotated tagging, and tag push. The checker runs module hygiene, formatting and
whitespace checks, one race-enabled suite, vet, and Linux amd64/arm64 cross-builds
using a maintained Go 1.25 patch. Publication completes on successful tag push.
These remain the current requirements until deliberately revised. This roadmap
does not itself waive existing gates.
The implementation plan records the subsequent gate selection and publication
command. Current requirements belong to the
[release policy](../policy/release.md) and [runbook](../release.md).
## Target release contract
@@ -40,7 +41,7 @@ authorization, not the standing local-commit policy.
The command validates the exact candidate once. An optional validation-only mode
may support diagnosis but is not a prerequisite followed by duplicate validation.
Do not require both everyday and release checkers. An implementation need not
introduce a persistent validation cache merely to replace today's manual record.
introduce a persistent validation cache merely to replace the former manual record.
Mechanical guards ensure a clean worktree/index on the primary branch, an unused
valid version locally and on the authoritative remote, a matching release note,
@@ -54,12 +55,11 @@ consumer installation, or optional verification. Do not add a successful-push
remote read-back gate. If future artifact channels are adopted, delivery status
must remain separate; this task introduces none.
## Gate review target
## Selected gate rationale
Keep the full deterministic offline suite as the core check. The selected gates
below provide distinct protection without repeating validation. Their rationale
belongs in the adopted release policy, with commands in the runbook and tooling
once implemented.
belongs in the adopted release policy, with commands in the runbook and tooling.
| Check | Selected end state and rationale |
| --- | --- |