Retire duplicated release scripts and tests
This commit is contained in:
@@ -139,7 +139,7 @@ second required Go/test run; all commands, version placeholders, and documented
|
||||
failure states match ReleaseKit v0.2.0. Do not execute its real publication
|
||||
command in this stage.
|
||||
|
||||
## Stage 5: Retire duplicated machinery and update developer guidance
|
||||
## Stage 5: Retire duplicated machinery and update developer guidance — Complete
|
||||
|
||||
1. Remove `scripts/release.sh`, `scripts/release-check.sh`, and
|
||||
`release_publish_test.go` after Stages 1–4 supply the replacement. Remove
|
||||
|
||||
@@ -1,22 +1,24 @@
|
||||
# Adopt ReleaseKit for source releases
|
||||
|
||||
Status: Proposed. This roadmap uses ReleaseKit v0.2.0 (tagged commit
|
||||
Status: In progress. The ReleaseKit profile and workflow are in place; isolated
|
||||
fixture verification remains in the implementation plan. This roadmap uses
|
||||
ReleaseKit v0.2.0 (tagged commit
|
||||
`e030794969fb7787e647a90bbc4eb81bd0610f07`) as the initial adoption
|
||||
baseline. The [ReleaseKit release note](https://gitea.maximumdirect.net/eric/ReleaseKit/src/tag/v0.2.0/docs/releases/v0.2.0.md)
|
||||
summarizes its available capabilities. The staged
|
||||
[implementation plan](implementation.md) owns task order and acceptance checks.
|
||||
|
||||
## Purpose and current baseline
|
||||
## Purpose and pre-adoption baseline
|
||||
|
||||
ConfigKit wants to use a common release process and retire duplicated local
|
||||
release machinery. Today, [the release procedure](../release.md) uses
|
||||
ConfigKit adopted a common release process to replace duplicated local release
|
||||
machinery. Before this migration, [the release procedure](../release.md) used
|
||||
`scripts/release.sh` and `scripts/release-check.sh` to validate a committed
|
||||
candidate, push it to `main`, and publish an annotated tag. Dedicated tests
|
||||
exercise those scripts. The selected gates are one offline race-enabled Go
|
||||
candidate, push it to `main`, and publish an annotated tag; dedicated tests
|
||||
exercised those scripts. That workflow selected one offline race-enabled Go
|
||||
suite on a maintained Go 1.25 patch, one full vet pass, and CGO-disabled package
|
||||
builds for Linux amd64 and arm64. The checked-in note and immutable tag are the
|
||||
only declared deliverables. CI and macOS checks do not gate publication; no
|
||||
hosted release page is declared.
|
||||
builds for Linux amd64 and arm64. The checked-in note and immutable tag were
|
||||
the only declared deliverables. CI and macOS checks did not gate publication;
|
||||
no hosted release page was declared.
|
||||
|
||||
ReleaseKit v0.2.0 offers [profile selections](https://gitea.maximumdirect.net/eric/ReleaseKit/src/tag/v0.2.0/docs/config.md)
|
||||
for that same test, vet, and source-only compilation set. It runs the test
|
||||
@@ -64,22 +66,20 @@ correctness fix requires it. This directive is the consumer minimum, not the
|
||||
release toolchain version. Use the latest locally available patch in the
|
||||
selected series to build the pinned ReleaseKit tool and run its validation,
|
||||
provided it meets that minimum and has native race prerequisites available.
|
||||
ReleaseKit sets `GOTOOLCHAIN=local` for its child commands, so ConfigKit's
|
||||
existing `CONFIGKIT_BASELINE_TOOLCHAIN` environment selection cannot select a
|
||||
different validation toolchain. Prepare the tool and dependencies before
|
||||
offline candidate validation; any `go.mod` change belongs in the committed
|
||||
candidate. Review a minimum-Go increase as a compatibility change and explain
|
||||
its consumer impact in the release note. Before v1.0.0, an intentional
|
||||
increase requires a minor rather than patch release under ConfigKit's
|
||||
ReleaseKit sets `GOTOOLCHAIN=local` for its child commands, so the same selected
|
||||
Go executable must remain first on `PATH` for the tool build and validation.
|
||||
Prepare the tool and dependencies before offline candidate validation; any
|
||||
`go.mod` change belongs in the committed candidate. Review a minimum-Go increase
|
||||
as a compatibility change and explain its consumer impact in the release note.
|
||||
Before v1.0.0, an intentional increase requires a minor rather than patch
|
||||
release under ConfigKit's
|
||||
[versioning policy](../policy/release.md#versioning-and-compatibility).
|
||||
|
||||
Use ReleaseKit's note-heading and exact effective-push-URL guards without
|
||||
recreating ConfigKit's current exact-first-line-title or fetch-URL checks.
|
||||
Continue writing release notes with the required `# ConfigKit <version>`
|
||||
first line, while aligning release policy with the guards that actually run.
|
||||
ReleaseKit v0.2.0 checks the release-note H1 and exact effective push URL; it
|
||||
does not assert the required first-line format or the configured fetch URL.
|
||||
Continue writing notes with the required `# ConfigKit <version>` first line.
|
||||
Per-test skip listings are optional diagnostic output, not a release gate;
|
||||
ReleaseKit's one nonverbose standard suite still blocks publication on test
|
||||
failure.
|
||||
ReleaseKit's one standard suite still blocks publication on test failure.
|
||||
|
||||
ReleaseKit owns generic candidate guards, test and compile coordination, tag
|
||||
creation, publication, and push recovery. ConfigKit owns version selection,
|
||||
@@ -89,36 +89,26 @@ release process adds no ConfigKit public API or runtime use of ReleaseKit.
|
||||
|
||||
## Changes from the baseline
|
||||
|
||||
- Add the minimal profile and declare ReleaseKit v0.2.0 as a tool dependency in
|
||||
`go.mod`, updating `go.sum` and reviewing its dependency and license impact.
|
||||
Document how to build the module-selected tool before offline validation.
|
||||
The release runbook should record the selected series' minimum in `go.mod`,
|
||||
use its latest locally available patch to build ReleaseKit and validate the
|
||||
candidate, and keep the selected release command small. Do not re-create
|
||||
generic Git guards or Go check sequencing in a wrapper.
|
||||
- Revise the [release policy](../policy/release.md) and
|
||||
- Added the minimal profile and declared ReleaseKit v0.2.0 as a tool dependency
|
||||
in `go.mod`, with resolved checksums in `go.sum`. The library has no runtime
|
||||
import of ReleaseKit, and tooling use alone requires no attribution entry.
|
||||
- Updated the [release policy](../policy/release.md) and
|
||||
[maintainer procedure](../release.md) for candidate publication to `main`
|
||||
before ReleaseKit's command, its effective-push-URL check, recurring Go
|
||||
version selection and compatibility review, one selected validation pass,
|
||||
tag-only publication, ReleaseKit's standard note and URL guards, optional
|
||||
skip listings, and ReleaseKit's failure states. Preserve ConfigKit's
|
||||
source-only deliverables, supported targets, and no-CI completion rule.
|
||||
- Update the [development guide](../development.md) so its release guidance and
|
||||
task-to-test map describe the adopted process. Keep ordinary development
|
||||
checks separate from release gates; review other references to the retired
|
||||
scripts.
|
||||
- Retire `scripts/release.sh`, `scripts/release-check.sh`, and their duplicated
|
||||
publication and gate tests once ReleaseKit takes over. Preserve the
|
||||
development-check behavior and its tests from `release_check_test.go`.
|
||||
Retain only a proportionate ConfigKit integration test for the selected
|
||||
profile and invocation where it detects a real wiring error.
|
||||
- Verify the migration without publishing a real ConfigKit version: exercise
|
||||
the selected profile and release command against an isolated candidate and
|
||||
temporary Git remote, including a validation failure and successful tag
|
||||
publication. Confirm that the candidate's `go.mod` records the selected
|
||||
series' minimum or a required higher patch, and that the same selected Go
|
||||
executable builds ReleaseKit and runs the selected gates once. Do not make
|
||||
a separate successful CI run a release condition.
|
||||
before ReleaseKit validation, recurring Go version selection and compatibility
|
||||
review, the selected validation set, tag-only publication, ReleaseKit's note
|
||||
and URL guards, and its failure states. Source-only deliverables, supported
|
||||
targets, and the no-CI completion rule remain unchanged.
|
||||
- Updated the [development guide](../development.md) to distinguish everyday
|
||||
development checks from release validation and to document the selected
|
||||
profile test.
|
||||
- Retired the local release scripts and duplicated publication/gate tests.
|
||||
The development-check test and small profile-wiring test remain; generic
|
||||
ReleaseKit publication behavior is not duplicated in ConfigKit's tests.
|
||||
- The remaining migration verification exercises the selected profile and
|
||||
release command against isolated candidates and a temporary Git remote,
|
||||
including validation failure and successful tag publication. It confirms
|
||||
the selected Go minimum and one invocation of each selected gate, without
|
||||
publishing a real ConfigKit version or requiring a separate CI run.
|
||||
|
||||
Historical tags and release notes remain unchanged. This adoption work does
|
||||
not itself authorize publication of a ConfigKit version.
|
||||
|
||||
Reference in New Issue
Block a user