Align release policy and operational documentation
This commit is contained in:
@@ -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 |
|
||||
| --- | --- |
|
||||
|
||||
Reference in New Issue
Block a user