diff --git a/docs/policy/release.md b/docs/policy/release.md index 9598fe0..38cf644 100644 --- a/docs/policy/release.md +++ b/docs/policy/release.md @@ -54,10 +54,11 @@ authoritative primary branch, completes the release. The source commit may be pushed before the tag or published together with it through an atomic push. The procedure must choose and document the supported approach. -ConfigKit uses sequential explicit pushes: first the captured candidate to -authoritative `main`, then the annotated tag. Its -[release procedure](../release.md) names `origin` and checks that its fetch and -push destinations resolve to the authoritative URL. +ConfigKit uses sequential publication: first push the committed candidate to +authoritative `main`, then invoke ReleaseKit once to validate that candidate and +publish its annotated tag. The [release procedure](../release.md) names +`origin`; ReleaseKit checks its exact effective push URL before validation and +tag publication. Release commands must finish at successful publication. They must not wait for or poll CI, require successful CI status, inspect downloadable artifacts, or @@ -76,8 +77,9 @@ the tagged source. The procedure must identify those deliverables and the responsibility of their automation. Published deliverables must be traceable to that source and identify the same version. -ConfigKit currently declares no additional deliverables. Its source-tag push -is the completion point. +ConfigKit currently declares no additional deliverables. Confirmed publication +of the intended source tag is the completion point. CI, macOS validation, +hosted delivery, and consumer retrieval are outside the release gates. ## Versioning And Compatibility @@ -114,7 +116,8 @@ Every new release must include `docs/releases/.md` in the tagged source tree. Use the complete version tag as the filename and begin with a title containing the product name and that exact version. -ConfigKit requires the first line `# ConfigKit `. +ConfigKit requires the first line `# ConfigKit `. ReleaseKit v0.2.0's +publication guard checks the release-note H1 for the product and version. Include a short summary and any relevant compatibility impact or upgrade instructions. Choose sections suited to the release and keep the note @@ -146,10 +149,9 @@ checks publication state, and publishes the intended refs. A validation-only mode or command may be provided for diagnosis, but must not be a required step before publication repeats the same checks. -ConfigKit uses `./scripts/release.sh vMAJOR.MINOR.PATCH`. The separate -`scripts/release-check.sh` remains an optional diagnostic command; the -publication command invokes it once and does not use a persistent candidate -record. +ConfigKit uses the module-selected ReleaseKit CLI's `publish +vMAJOR.MINOR.PATCH` command. Its `check` command is optional for diagnosis; it +is not a required preliminary pass to publication. Run the complete deterministic, offline default test suite once for the final candidate, following the [testing policy](testing.md). For repositories that @@ -157,13 +159,24 @@ publish builds, verify the required build targets. Select those targets for the application's actual support commitments; native testing on each platform and access to particular hardware are not default release prerequisites. -ConfigKit's one maintained Go 1.25 baseline runs the full suite with the race -detector and test-time vet disabled. This protects library behavior, ownership, -and concurrent use; the suite already includes examples, consumer fixtures, -documentation links, and package boundaries. One full vet pass adds static -checks beyond the test-time subset. CGO-disabled Linux amd64 and arm64 builds -cover supported configurations distinct from native race compilation. macOS -and newer-toolchain checks are optional. +For release preparation, record the initial stable release of the newest +locally available Go series in `go.mod`'s `go` directive. Retain a higher patch +minimum only when required by a dependency or a specific correctness fix. Use +the latest locally available compatible patch in that series, selected with +`GOTOOLCHAIN=local`, to build the module-selected ReleaseKit CLI and validate the +candidate, provided it meets the current `go.mod` minimum. Review any +minimum-version increase under the existing compatibility rules. Prepare +dependencies and build the tool before offline validation; the publication +command is the required validation run, with no separate successful test or CI +run required before it. + +The selected profile runs the complete deterministic, offline default suite +once with the race detector and test-time vet disabled. The suite already +includes examples, consumer fixtures, documentation links, and package +boundaries. One full vet pass adds static checks beyond the test-time subset. +CGO-disabled Linux amd64 and arm64 package compilation covers supported +configurations distinct from native race compilation. macOS and newer-toolchain +checks are optional. Additional gates must address a concrete risk that the existing checks do not adequately cover. Do not automatically require linting, race testing, module @@ -172,9 +185,10 @@ expanded platform matrices solely because they are possible. Retain such checks when their distinct protection justifies their cost. A one-time migration check must not silently become a permanent release requirement. -The selected Go commands use readonly module mode with `GOPROXY=off`; acquire -the baseline toolchain and dependencies before validation. Formatting and -whitespace remain ordinary development checks in `scripts/check.sh`. +ReleaseKit runs its selected Go commands with readonly module mode and +`GOPROXY=off`; acquire dependencies and build the tool before candidate +validation. Formatting and whitespace remain ordinary development checks in +`scripts/check.sh`. Review module tidiness when dependencies change, not as a release gate. Release tests must not require real credentials, mutable application services, @@ -206,16 +220,19 @@ Automate the checks needed to publish the intended source under a fresh version: authoritative remote; - the worktree and index are clean on the primary release branch; - the source being published is the exact candidate that passed validation, - including its matching release note; + including its matching release note H1; - the remote primary branch can be advanced to that candidate without discarding remote history, and is published before the tag; and - the tag identifies the validated candidate and only the intended refs are published. -ConfigKit also checks that `origin` has exactly the authoritative fetch and -push destination, including configured push URLs. The command checks the -candidate and unused version again after validation, and checks local state -before creating the tag. Ignored local files do not block publication. +ReleaseKit checks that `origin`'s effective push URL exactly matches the +authoritative URL before candidate validation. This does not assert the +configured fetch URL or require the release-note H1 to be the first line; the +required `# ConfigKit ` first-line format remains a content rule. The +command checks the candidate and unused version again after validation, and +checks local state before creating the tag. Ignored local files do not block +publication. Fetch the authoritative branch and tag state as needed for these checks. Do not force branch or tag updates to bypass a failed guard. Publish explicit diff --git a/docs/roadmap/implementation.md b/docs/roadmap/implementation.md index 71961b3..a899e92 100644 --- a/docs/roadmap/implementation.md +++ b/docs/roadmap/implementation.md @@ -62,7 +62,7 @@ Completion evidence: the profile is valid JSON, the focused test and ordinary Go suite pass, and review shows only the selected gates and no binary or hosted delivery configuration. -## Stage 3: Align release policy with the adopted workflow +## Stage 3: Align release policy with the adopted workflow — Complete 1. Revise [the release policy](../policy/release.md) so candidate preparation explicitly publishes the committed candidate to authoritative `main`