eric/ConfigKit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Plan the single-command release workflow

Browse Source
This commit is contained in:
Eric Rakestraw
2026-09-28 00:52:16 +00:00
parent faf5ff8fa1
commit d6fe498652
2 changed files with 190 additions and 272 deletions
Download Patch File Download Diff File Expand all files Collapse all files

59
docs/roadmap/release.md
View File

@@ -1,6 +1,7 @@
# Single-Command Release Workflow and Gate Review
Status: accepted target; detailed design and implementation planning remain separate.
Status: accepted target; execution order and acceptance checks are defined in the
[implementation plan](implementation.md).
## Intent and baseline
@@ -55,19 +56,19 @@ must remain separate; this task introduces none.
## Gate review target
Keep the full deterministic offline suite as the core check. Evaluate every
additional current gate for distinct protection, cost, and overlap; do not retain
or remove it solely because it appears in a template. Record the selected rationale
in the adopted release policy, with commands in the runbook and implementation.
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.
| Current check | Review question |
| Check | Selected end state and rationale |
| --- | --- |
| Race detector | Does its coverage of ownership and concurrent loads justify retaining it as the single full-suite mode? Avoid a second ordinary suite. |
| Vet | What additional static defects does it catch beyond the test invocation, and is that protection worth a separate gate? |
| Module hygiene | Is reproducibility protection distinct from ordinary dependency-change review and offline tests? |
| Formatting and whitespace | Which checks belong in ordinary development rather than blocking publication? Avoid repeated scans without distinct value. |
| Linux amd64/arm64 builds | Preserve existing supported targets unless deliberately changed; remove only demonstrably redundant work, not support commitments by implication. |
| Toolchain selection | Preserve minimum-line validation without adding a second-toolchain gate or per-release latest-version research. |
| Race detector | One full race-enabled suite protects ownership and concurrent loads; no second ordinary suite. |
| Vet | One full vet pass provides additional static analysis; disable the smaller test-time vet pass to avoid overlap. |
| Module hygiene | Tidiness belongs to dependency-change review, not a recurring release audit. Offline tests/builds use readonly module mode to avoid incidental manifest edits. |
| Formatting and whitespace | Ordinary development checks, not publication gates; the everyday checker remains unchanged. |
| Linux amd64/arm64 builds | Retain both CGO-disabled builds: they cover supported configurations distinct from native race compilation. |
| Toolchain selection | One maintained Go 1.25 patch, with no second-toolchain gate or per-release latest-version research. |
Examples, consumer fixtures, documentation links, and import/public boundary tests
are already in the suite; they must not become separately repeated release checks.
@@ -103,35 +104,18 @@ Tests should exercise success and meaningful failure/recovery paths in disposabl
local repositories, without real publication or credentials. Match coverage to
the chosen push strategy and protect against unintended refs or stale candidates.
Coordinate provenance and licensing with the [policy roadmap](policy.md).
Preserve provenance and licensing established by the completed
[policy roadmap](policy.md).
Operational documentation changes land with the implementation they describe.
No library behavior, dependency update, release tag, or push is authorized by
implementing this roadmap alone.
## Open Decisions
## Publication strategy
### Final gate set
Recommendation: use the current single race suite and Linux support matrix as the
starting point, retaining additional checks only with specific nonredundant
justification. Assess the remaining checks during implementation planning before
changing the binding policy. This protects selected behavior without treating
the existing checker as an untouchable inventory.
Alternative: retain the entire existing checker and automate only publication.
This minimizes behavioral change and is a viable initial scope, but it does not
complete the requested gate review unless each retained check is justified.
### Publication strategy
Recommendation: retain explicit main-then-tag pushes inside the command. This
matches the proven local workflow and avoids a new dependency on atomic-push
support; recovery must describe a partially published sequence.
Alternative: atomically push main and the tag after validating remote ancestry.
This avoids a branch-only intermediate result but requires confirming server
support and adapting failure tests. Select one strategy in the implementation
plan rather than silently switching between them.
Use explicit main-then-tag pushes inside the command. This matches the proven
local workflow and avoids a new dependency on atomic-push support. A branch-only
intermediate result is possible; recovery distinguishes it from completed or
unknown publication. Atomic publication is not part of this target.
## Completion criteria
@@ -139,5 +123,4 @@ One documented command publishes a prepared candidate with the reviewed minimum
gate set, no duplicate suite runs, and automated exact-source safeguards. Local
regression tests demonstrate successful publication and safe failure handling.
The policy, runbook, and scripts agree, and successful tag publication is reported
without waiting for external completion evidence. Detailed stages belong in the
later implementation plan, not this target-state roadmap.
without waiting for external completion evidence.