# Release Policy **Base Policy Version:** 1.6 **Last Updated**: 2026-10-09 **Upstream Source:** [Standard Repository Policies](https://gitea.maximumdirect.net/eric/policy/src/commit/e833faddf120c789a9b45348edaf75720de16348/docs/policy/release.md) ## Purpose This policy defines a proportionate workflow for validating and publishing an intended source revision under a fresh version. Releases should require little routine intervention, avoid repeated work, and preserve published contents. Adopt stronger verification or reproducibility requirements through an explicit project-specific decision justified by the intended audience and support needs. The repository-specific commands belong in `docs/release.md`. Historical release summaries belong in `docs/releases/`. The procedure must agree with the adopted policy and link to it rather than introduce additional release requirements. ## ConfigKit Applicability ConfigKit publishes a source-only Go module. Its declared deliverables are the immutable annotated source tag and version-matched checked-in release note. Standalone binaries, container images, hosted release objects, and separate registry publication are not required. Additional channels require a deliberate update to the policy and procedure. The Go API, documented YAML and resolution semantics, and structured diagnostic contracts participate in compatibility review. A signature-preserving change can still break consumers. Human diagnostic wording is stable only where a contract expressly promises it. Minimum Go version and platform support changes also require an explicit compatibility assessment. ### Platform Support Linux is the release-validated platform. macOS has best-effort support: keeping it working remains desirable, but neither native macOS validation nor Darwin cross-builds are release gates. Missing macOS evidence or a macOS-specific failure does not by itself block a release. Voluntary checks and fixes are welcome; there is no guarantee that each release has been validated on macOS. The [release procedure](../release.md#release-identity-and-support) owns target architectures and required Linux checks. Historical release notes and their validation records remain unchanged. ## Release Model And Completion A source release identifies one exact committed source revision through an immutable version tag and a version-matched, checked-in release note. The primary release branch is `main` unless the adopted policy specifies otherwise. The procedure must name the authoritative publication remote. A successful push of the intended tag, with its source commit available on the 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 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 check consumer installation or Go module availability as completion gates. A failed or ambiguous push requires resolving the authoritative remote state before declaring success or retrying; successful pushes do not require a separate remote read-back gate. Remote tag read-back and fresh consumer retrieval are optional and non-gating after successful publication. A failed push receives one bounded check of the authoritative ref; do not poll or blindly retry. Repositories may publish source only. Additional binaries, images, packages, checksums, or other declared deliverables may be published asynchronously from 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. 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 Stable releases use Semantic Versioning in the form `vMAJOR.MINOR.PATCH`, with no leading zeroes. Prereleases require an explicit adopted policy defining their format and use. ConfigKit does not support prereleases. The selected version must be unused locally and on the authoritative remote. Do not require queries to every configured remote or publication service. A version known to have already been published must not be reused, even if the normal guards do not inspect that channel. Adding a distribution channel requires a deliberate update to the policy and procedure where needed. For releases at or after `v1.0.0`: - a major release may make intentional incompatible changes; - a minor release may add backward-compatible behavior or raise the Go consumer minimum as described below; and - a patch release may make backward-compatible fixes. Before `v1.0.0`, a minor release may change a documented public, operational, configuration, data, integration, or compatibility contract when the release note explains the impact and required consumer action. A patch release must not intentionally break those contracts within its minor line. Additional compatibility promises and deliberate exceptions belong in the adopted policy or canonical contract documentation. Release notes explain changes; they do not redefine current compatibility contracts. ## Consumer Minimum And Release Toolchain Distinguish the minimum toolchain supported for consumers from the toolchain maintainers use to build and validate a release. Record the consumer minimum in the language's standard metadata and explain its support meaning in canonical documentation. Define the selected release toolchain and its setup commands in `docs/release.md`. Toolchain selection and upgrade cadence are repository-specific choices. For Go repositories, normally declare the initial stable release of the selected series as the consumer minimum, such as `go 1.26.0`. Use a higher patch minimum when a dependency or an identified correctness fix requires it, and document the reason. For release-policy purposes, successful build and release validation on the selected Go patch release are sufficient to presume support across that Go series, subject to the declared consumer minimum and concrete evidence of incompatibility. Investigate specific compatibility concerns as they arise. Use the selected release toolchain for candidate validation and release builds, including CI jobs performing those tasks. A newer validation patch version alone leaves the consumer minimum unchanged. A minor release may raise the Go consumer minimum, including from one Go series to the next, both before and after `v1.0.0`. This is an explicit exception to the backward-compatibility requirement for minor releases. Patch releases preserve the consumer minimum. Explain an increase's impact and required consumer action in the release note. Other incompatible changes remain subject to the versioning rules above. ### ConfigKit Toolchain Selection For minor and major releases, select the newest stable Go series available in the development environment. For patch releases, retain the series recorded in `go.mod` and its consumer minimum. Use the latest locally available compatible patch in the selected series, with `GOTOOLCHAIN=local`, to build the module-selected ReleaseKit CLI and validate the candidate. The same Go executable builds the tool and runs its validation commands. ## Release Documentation And Preparation 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 `. 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 proportionate to the change. Keep exact current contracts in their canonical documents and update affected documentation with the behavior change. Link to those documents from the note where useful. If annotated tags are used, derive their summary from the checked-in note. ConfigKit uses the complete checked-in note as the annotated tag message. Include the release footer defined by the [OSS policy](oss.md#discoverability) in each new release document. The release procedure defines the concrete URLs and publication mechanics. Prepare these links with the release note; they do not add a network check or approval gate. If a hosted download page is used in a future channel, preserve the footer there. Handle version selection, release-note content, and retirement of completed roadmaps during preparation. Preserve planned and deferred work and repair affected links when retiring roadmaps. Reuse ordinary change review for unintended files, credentials, and private data. Scope release-content review to the tagged source. ## Candidate Validation Provide one publication command that validates the final committed candidate, 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 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 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. 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 hygiene audits, documentation audits, credential scans, example validation, or 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. 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, paid APIs, provider probes, or inference calls. The procedure may describe dependency preparation separately from offline validation. Avoid duplicate validation across release phases. Successful checks for the same final candidate need not be repeated solely to satisfy another phase; any reuse must clearly apply to that exact candidate. Persistent validation caches are not required. If the candidate changes, validate the new candidate. Cheap publication-state checks may be repeated immediately before pushing because local or remote state may have changed during validation. Automate mechanical guards. Human review gates are strongly disfavored: add one only through an explicit project-specific policy decision explaining the concrete risk and why ordinary change review or automation is insufficient. Do not add routine confirmations for checks the command can perform itself. Compatibility review, release-note accuracy, completed-roadmap retirement, and review for unintended files or credentials remain ordinary preparation. The executing agent may perform them without routine human approval or separate manual evidence records. Publication itself requires authorization. ## Publication Guards Automate the checks needed to publish the intended source under a fresh version: - the version has the adopted format and is unused locally and on the 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 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. 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 refs rather than all local tags. Do not require CI success, publication-service availability checks, or a separate manual confirmation for each guard. ## Immutability And Correction Published version tags and published contents are immutable. Do not move, overwrite, recreate, or delete a published tag, or replace a published artifact, checksum, signature, provenance statement, or release note under that version. The checked-in note at the immutable tag is that release's historical record. If validation fails before publication, correct and commit the candidate and rerun the publication command. If a push fails or its outcome is ambiguous, inspect the authoritative remote before retrying. Remove an unpublished local tag only after confirming it was never published or used by a release channel. An unavailable remote leaves publication status unknown; do not overwrite a tag to resolve uncertainty. Transient network, authentication, CI, or consumer-availability failures do not by themselves require a new version. A defect requiring changes to published source or contents requires a corrected commit, a new semantically appropriate version, a matching release note, and the release procedure again. Leave the original release intact. A channel's yank, deprecation, or advisory mechanism may warn consumers away from a defective release without replacing its contents or reusing its version. ## Repository Release Procedure Maintain `docs/release.md` as a short, executable maintainer runbook. It must identify prerequisites, the selected release toolchain, the primary branch and authoritative remote, version and note preparation, one publication command with local checks and guards, source-only deliverables, the successful-tag-push completion point, and partial or unknown-state recovery. Use copyable commands where practical. Keep optional diagnostics and consumer verification clearly optional. The procedure must not turn preparation work, ordinary change review, or post-publication investigation into additional release gates. ## Policy Exceptions The following historical exceptions do not change the current release workflow. For v0.1.1 only, the maintainer approved renaming the reserved `_configkit` key to `configkit` as an error-correcting point release because there are no current consumers. This intentionally changes the v0.1.0 configuration contract without a minor-version increment. The release note must explain the renamed directive, the lack of a legacy alias, and the newly reserved application key. This exception does not apply to subsequent releases or waive any validation or publication gate. For v0.2.0 only, the maintainer accepted the successful native macOS check at `244104f` for the final candidate, provided subsequent changes are documentation only. The final candidate still requires the complete Linux release checker. This exception waives only repeating the macOS check after those documentation changes; it does not waive other publication or verification gates.