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,6 +1,6 @@
# Release Workflow Implementation Plan
Status: ready for implementation; no stages completed by this planning pass.
Status: implemented on 2026-09-28. All stages are complete.
Implement the [release roadmap](release.md) in the numbered order below. Each
stage is a bounded work unit for a gpt-5.6-terra coding agent; finish its tests
@@ -177,6 +177,12 @@ no longer require a manually recorded candidate before single-command publicatio
## Stage 3 — Complete documentation alignment and integrated validation
**Completed 2026-09-28.** Reconciled the adopted release policy with its pinned
upstream source and ConfigKit decisions; aligned the runbook, development guide,
and roadmap records with the implemented command. Bash syntax, focused release
tests, local documentation links, whitespace review, and the final real baseline
release checker passed on Linux. No publication or push was performed.
Reconcile `docs/policy/release.md` with the pinned upstream release policy. Adopt
shared paragraphs verbatim except for substantive local decisions. Remove the
temporary deferral, all-remotes freshness rule, and stale prospective v0.3.0 note

View File

@@ -1,7 +1,7 @@
# Standard Policy Documentation Alignment
Status: implemented on 2026-09-28. The [implementation record](implementation.md)
contains the completed stages and validation evidence.
Status: implemented on 2026-09-28. The completed implementation record and
validation evidence are preserved at `faf5ff8:docs/roadmap/implementation.md`.
ConfigKit's seven [adopted policies](../policy/meta.md) now identify the pinned
Standard Repository Policies revision
@@ -11,10 +11,9 @@ applicable policies. [COPYRIGHT](../../COPYRIGHT) and the
[attribution notices](../oss/attribution.md) identify the separately licensed
adapted policy and orientation material.
The [release policy](../policy/release.md) retains ConfigKit's existing
operational requirements. The [maintainer runbook](../release.md) remains their
command owner. The separate [release-workflow roadmap](release.md) owns future
publication automation and gate review; this policy alignment did not implement
that workflow.
The [release policy](../policy/release.md) and
[maintainer runbook](../release.md) own current release requirements and
operations. The separate [release-workflow roadmap](release.md) records the
subsequent publication-automation work.
These completed records remain until normal release preparation retires them.

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 |
| --- | --- |