Separate the Go minimum from the release toolchain
This commit is contained in:
@@ -210,12 +210,17 @@ annotated stable SemVer tags. It has no binaries, hosted download pages, or
|
||||
asynchronous deliverables. The source commit is pushed through main before the
|
||||
tag. The [release procedure](../release.md) owns commands and recovery.
|
||||
|
||||
Release preparation advances Promptkit's `go.mod` Go requirement to the latest
|
||||
Go version available in the development environment. Use that same toolchain
|
||||
for candidate validation and to build any maintainer release executable.
|
||||
Commit the module update before validating the final candidate, and describe
|
||||
the resulting minimum Go requirement and compatibility impact in the release
|
||||
note under the versioning policy above.
|
||||
Release preparation advances Promptkit's `go.mod` Go requirement to the initial
|
||||
stable release of the latest Go series available in the development environment
|
||||
(for example, `go 1.26.0`). Use a higher patch minimum when required by a
|
||||
dependency or a specific correctness fix, rather than recording the maintainer's
|
||||
current patch solely because it was used to build the release.
|
||||
|
||||
Use the latest locally available patch in that series for candidate validation
|
||||
and to build any maintainer release executable. Keep that same local toolchain
|
||||
active throughout those operations. Commit the module update before validating
|
||||
the final candidate, and describe a raised minimum Go requirement and its
|
||||
compatibility impact in the release note under the versioning policy above.
|
||||
|
||||
The existing publication script requires Summary, Compatibility, Upgrade, and
|
||||
Changes headings beneath a title of `# Promptkit vMAJOR.MINOR.PATCH`. State
|
||||
|
||||
@@ -11,16 +11,22 @@ Required tools are Git, Go with race-detector support, POSIX shell, and Python
|
||||
|
||||
Use the latest Go toolchain available in the development environment for
|
||||
release preparation and validation. Make that installation the active `go`
|
||||
command, then advance PromptKit's Go requirement before committing the
|
||||
candidate:
|
||||
command, then advance PromptKit's minimum Go requirement to that series' first
|
||||
stable release before committing the candidate:
|
||||
|
||||
```sh
|
||||
export GOTOOLCHAIN=local
|
||||
go version
|
||||
release_go_version=$(go env GOVERSION)
|
||||
go get "go@${release_go_version#go}"
|
||||
release_go_series=${release_go_version#go}
|
||||
release_go_series=${release_go_series%.*}
|
||||
go mod edit "-go=${release_go_series}.0"
|
||||
```
|
||||
|
||||
For example, building with Go 1.26.8 normally records `go 1.26.0`, not
|
||||
`go 1.26.8`. If a dependency or a specific correctness fix requires a higher
|
||||
patch minimum, use that minimum instead of reducing it to `.0`.
|
||||
|
||||
Include the module change in the candidate commit. Describe a raised minimum
|
||||
Go requirement in the release note and select the release version under the
|
||||
[compatibility policy](policy/release.md#versioning-and-compatibility).
|
||||
|
||||
@@ -4,6 +4,10 @@ Implement the agreed [adoption roadmap](releasekit.md) in the stages below,
|
||||
in order. Each stage is scoped for one Luna coding-agent prompt. This document
|
||||
owns the implementation steps; the roadmap owns purpose and selected policy.
|
||||
|
||||
Status: Stage 1's tool selection and dependency preparation are complete in
|
||||
`3ca01ae`. The agreed series-based Go minimum supersedes the original patch-based
|
||||
requirement. Resume adoption at Stage 2 after this revision.
|
||||
|
||||
## Baseline And Working Rules
|
||||
|
||||
- Planning baseline: PromptKit commit
|
||||
@@ -47,7 +51,8 @@ owns the implementation steps; the roadmap owns purpose and selected policy.
|
||||
## Stage 1 — Declare The Released Tool And Advance The Go Requirement
|
||||
|
||||
**Outcome:** Module metadata selects ReleaseKit as a maintainer tool and records
|
||||
the development environment's current Go requirement.
|
||||
the initial stable version of the development environment's current Go series
|
||||
as the consumer minimum, subject to required higher patch minima.
|
||||
|
||||
**Read:** `go.mod`, `go.sum`, the runbook's
|
||||
[preparation step](../release.md#prepare-the-candidate), and the OSS policy.
|
||||
@@ -56,10 +61,12 @@ the development environment's current Go requirement.
|
||||
|
||||
1. From the repository root, use the active latest local Go installation:
|
||||
`export GOTOOLCHAIN=local`; capture `go env GOVERSION`.
|
||||
2. Advance the requirement with
|
||||
`go get "go@${release_go_version#go}"`, where `release_go_version` contains
|
||||
that captured value. This is preparation before the resulting candidate
|
||||
commit, not an operation performed inside publication.
|
||||
2. Follow the runbook's series-based requirement update: strip the `go` prefix
|
||||
and final patch component from the captured version, then use
|
||||
`go mod edit "-go=${release_go_series}.0"`. For example, local Go 1.26.8
|
||||
normally records `go 1.26.0`. Retain a higher patch minimum if required by a
|
||||
dependency or a specific correctness fix. This is preparation before the
|
||||
resulting candidate commit, not an operation performed inside publication.
|
||||
3. Add the tool with
|
||||
`go get -tool gitea.maximumdirect.net/eric/ReleaseKit/cmd/releasekit@v0.2.0`.
|
||||
Use a Go `tool` declaration, not an artificial runtime import or a
|
||||
@@ -295,8 +302,9 @@ and recovery guidance, and the affected canonical documentation.
|
||||
wiring check as focused development validation, not a recurring release
|
||||
requirement or part of default Go tests.
|
||||
7. Rewrite the relevant `docs/release.md` sections around:
|
||||
activate the latest available local Go; update its requirement before the
|
||||
candidate commit; prepare module caches; author the note/footer; retire
|
||||
activate the latest available local Go; record its series-based minimum
|
||||
(or a required higher patch minimum) before the candidate commit;
|
||||
prepare module caches; author the note/footer; retire
|
||||
completed roadmaps; ordinary review/commit; push `main`; run the single
|
||||
publication command. Preparation commands may update module metadata before
|
||||
commit; bootstrap/validation preserve the final candidate.
|
||||
@@ -362,8 +370,9 @@ completion criteria.
|
||||
|
||||
- The final source-only publication command delegates to released ReleaseKit;
|
||||
the committed profile is the single local declaration of selected checks.
|
||||
- Go metadata records the preparation-time requirement; tool build, native
|
||||
validation and examples use the same selected local Go installation.
|
||||
- Go metadata records the series-based minimum or a required higher patch
|
||||
minimum; tool build, native validation and examples use the same selected
|
||||
latest-local-patch Go installation, independently of that consumer minimum.
|
||||
- Profile-selected shared validation and the real consumer examples pass on the
|
||||
complete source snapshot, while fixture failures prevent publication.
|
||||
- No runtime ReleaseKit import, local module replacement, extra release gate,
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# ReleaseKit Adoption Roadmap
|
||||
|
||||
Status: Adoption scope agreed; implementation has not started.
|
||||
Status: Tool dependency selected; remaining adoption work is pending.
|
||||
The [implementation plan](implementation.md) owns the ordered migration steps.
|
||||
|
||||
## Purpose
|
||||
@@ -71,10 +71,13 @@ push result. Tool bootstrap and dependency preparation precede offline
|
||||
candidate validation. The wrapper's responsibility is tool invocation;
|
||||
ReleaseKit owns candidate guards, validation coordination, tags, and recovery.
|
||||
|
||||
Release preparation advances PromptKit's `go.mod` Go requirement to the latest
|
||||
Go version available in the development environment. The
|
||||
Release preparation records the initial stable release of the latest locally
|
||||
available Go series as PromptKit's minimum requirement, retaining a higher patch
|
||||
minimum where needed by a dependency or a specific correctness fix. The
|
||||
[runbook preparation step](../release.md#prepare-the-candidate) makes that
|
||||
toolchain active before committing the candidate. Use the same Go version
|
||||
series' latest locally available patch active before committing the candidate.
|
||||
The module minimum and build toolchain are separate: for example, `go 1.26.0`
|
||||
can be built and validated with Go 1.26.8. Use the same local Go version
|
||||
to build ReleaseKit and run PromptKit's release validation, including the
|
||||
consumer examples. Local tooling uses that selected installation rather than
|
||||
an executable previously built with a different Go version or an automatically
|
||||
@@ -203,7 +206,7 @@ Update the affected canonical owners when the implementation lands:
|
||||
| --- | --- |
|
||||
| `docs/policy/release.md` | Describe the shared validation selections, simpler note convention, adopted publication/recovery model, retired gates, and selected deliverables. Preserve the Go-update/same-toolchain requirement, existing compatibility policy, and catalog-profile policy. |
|
||||
| `docs/policy/testing.md` | Route release validation through ReleaseKit while retaining race, full vet, and the three consumer workflows. Distinguish ordinary development checks from committed-candidate validation. |
|
||||
| `docs/release.md` | Preserve the preparation-time update to the latest development-environment Go version; document building ReleaseKit with that same toolchain, dependency preparation, one publication command, and upstream recovery. |
|
||||
| `docs/release.md` | Preserve the preparation-time series-based Go minimum and latest-local-patch selection; document building ReleaseKit with that same toolchain, dependency preparation, one publication command, and upstream recovery. |
|
||||
| `docs/development.md` | Replace the old checker inventory and prerequisites with current tool ownership and focused development commands. |
|
||||
| `docs/oss/attribution.md` and related notices, if applicable | Apply the OSS policy to the selected tooling and any copied or adapted material according to actual use and distribution. Tool use alone is not a blanket attribution requirement. |
|
||||
|
||||
|
||||
Reference in New Issue
Block a user