|
|
|
|
@@ -1,6 +1,7 @@
|
|
|
|
|
# ReleaseKit v0.3.0 upgrade roadmap
|
|
|
|
|
|
|
|
|
|
Status: upgrade and Go 1.26.0 consumer minimum accepted; implementation not begun.
|
|
|
|
|
Status: implemented; ReleaseKit v0.3.0, Go 1.26.0 minimum, and Go 1.26.8
|
|
|
|
|
release toolchain are in place.
|
|
|
|
|
|
|
|
|
|
Date: 2026-10-08.
|
|
|
|
|
|
|
|
|
|
@@ -11,8 +12,8 @@ v0.3.0 and simultaneously raise CommandKit's declared Go consumer minimum to
|
|
|
|
|
1.26.0. The user has accepted both changes. Retain the existing root-module Go
|
|
|
|
|
tool dependency and source-only publication workflow.
|
|
|
|
|
|
|
|
|
|
This document defines the desired end state and work needed from the reviewed
|
|
|
|
|
baseline. A later implementation plan can define ordered execution steps. The
|
|
|
|
|
This document records the target state, completed upgrade work, and evidence
|
|
|
|
|
from the reviewed baseline. The
|
|
|
|
|
[release policy](../policy/release.md),
|
|
|
|
|
[architecture policy](../policy/architecture.md),
|
|
|
|
|
[agent policy](../policy/agents.md),
|
|
|
|
|
@@ -33,10 +34,10 @@ worktree. ReleaseKit v0.3.0 identifies commit
|
|
|
|
|
matched that revision during review. Its [release notes](https://gitea.maximumdirect.net/eric/ReleaseKit/src/commit/e43df4416e0ed987349b2ea04a2c68c25e552772/docs/releases/v0.3.0.md)
|
|
|
|
|
record the compatibility and upgrade guidance.
|
|
|
|
|
|
|
|
|
|
| Area | Current baseline | Target |
|
|
|
|
|
| Area | Reviewed baseline | Target |
|
|
|
|
|
| --- | --- | --- |
|
|
|
|
|
| Module | `go 1.25.5`; ReleaseKit v0.2.0 selected through a `tool` directive and module requirement. | `go 1.26.0`; the same CLI tool dependency selects ReleaseKit v0.3.0. |
|
|
|
|
|
| Release toolchain | Go 1.25.5 selected in the runbook. The review environment has Go 1.26.8. | One selected Go 1.26 patch toolchain, documented separately from the consumer minimum; see OD-1. |
|
|
|
|
|
| Release toolchain | Go 1.25.5 selected in the runbook. The review environment has Go 1.26.8. | Go 1.26.8, documented separately from the Go 1.26.0 consumer minimum. |
|
|
|
|
|
| Launcher | `scripts/release` builds the module-selected native CLI in readonly mode and delegates publication with argument, status, and stream preservation. | The same bootstrap and delegation use v0.3.0 under the selected compatible toolchain. |
|
|
|
|
|
| Profile | `releasekit.json` specifies product, remote, and expected push endpoint; validation uses the default suite. | The same minimal source-only profile. |
|
|
|
|
|
| Evidence | Deterministic launcher tests and an opt-in publication exercise against disposable local Git repositories exist. | Those boundaries work with the upgraded module selection and toolchain. |
|
|
|
|
|
@@ -44,8 +45,8 @@ record the compatibility and upgrade guidance.
|
|
|
|
|
|
|
|
|
|
The upstream CLI, profile schema, and public signatures are unchanged. ReleaseKit
|
|
|
|
|
itself raises its minimum from Go 1.25.0 to 1.26.0; its dependency versions are
|
|
|
|
|
unchanged from v0.2.0. No test suite or publication exercise was run during this
|
|
|
|
|
planning pass.
|
|
|
|
|
unchanged from v0.2.0. The original planning review did not run a test suite or
|
|
|
|
|
publication exercise; completed upgrade validation is recorded below.
|
|
|
|
|
|
|
|
|
|
## Target end state
|
|
|
|
|
|
|
|
|
|
@@ -99,73 +100,69 @@ delivery. Their improvements are available if those capabilities are deliberatel
|
|
|
|
|
selected later; this upgrade does not enable them. No CommandKit latency or
|
|
|
|
|
allocation target is part of adoption.
|
|
|
|
|
|
|
|
|
|
## Work needed
|
|
|
|
|
## Completed upgrade work
|
|
|
|
|
|
|
|
|
|
### Module and toolchain alignment
|
|
|
|
|
|
|
|
|
|
- Select the release-validation patch under OD-1 and document its installation
|
|
|
|
|
- [x] Select Go 1.26.8 under OD-1 and document its installation
|
|
|
|
|
and `PATH` setup in the runbook. Use that toolchain for upgrade validation and
|
|
|
|
|
subsequent release tasks governed by the procedure.
|
|
|
|
|
- Upgrade the existing CLI tool dependency to v0.3.0 and set the Go directive to
|
|
|
|
|
- [x] Upgrade the existing CLI tool dependency to v0.3.0 and set the Go directive to
|
|
|
|
|
exactly 1.26.0 using ordinary Go module tooling. Review the resulting module
|
|
|
|
|
and checksum changes, including any automatically generated toolchain metadata.
|
|
|
|
|
Keep the consumer floor separate from the maintainer patch selection.
|
|
|
|
|
- Prepare dependencies before offline validation. The local sibling checkout is
|
|
|
|
|
- [x] Prepare dependencies before offline validation. The local sibling checkout is
|
|
|
|
|
review evidence, not a replacement module or build prerequisite. Diagnose any
|
|
|
|
|
checksum failure using upstream guidance and retain checksum verification.
|
|
|
|
|
- Review incidental module changes. ConfigKit, PromptKit, and backend upgrades
|
|
|
|
|
- [x] Review incidental module changes. ConfigKit, PromptKit, and backend upgrades
|
|
|
|
|
are separate work; v0.3.0 does not require new versions of its own dependencies.
|
|
|
|
|
|
|
|
|
|
### Launcher and profile verification
|
|
|
|
|
|
|
|
|
|
- Confirm the existing launcher builds the upgraded native executable from the
|
|
|
|
|
- [x] Confirm the existing launcher builds the upgraded native executable from the
|
|
|
|
|
module-selected package and preserves publication arguments, streams, and
|
|
|
|
|
statuses. Confirm that the executable identifies ReleaseKit v0.3.0.
|
|
|
|
|
- Retain the current profile and launcher design. Change implementation only if
|
|
|
|
|
- [x] Retain the current profile and launcher design. Change implementation only if
|
|
|
|
|
a demonstrated compatibility issue requires it; no migration is indicated by
|
|
|
|
|
the reviewed upstream CLI or schema.
|
|
|
|
|
- Reuse existing launcher tests. Adjust fixtures only where the selected version
|
|
|
|
|
- [x] Reuse existing launcher tests. Adjust fixtures only where the selected version
|
|
|
|
|
or Go requirement actually affects their behavior. An older version string
|
|
|
|
|
used to test rejection of an independent package pin need not be replaced just
|
|
|
|
|
because the adopted version changes.
|
|
|
|
|
|
|
|
|
|
### Canonical documentation and provenance
|
|
|
|
|
|
|
|
|
|
- Update [docs/policy/release.md](../policy/release.md) to identify the selected
|
|
|
|
|
- [x] Update [docs/policy/release.md](../policy/release.md) to identify the selected
|
|
|
|
|
ReleaseKit version while retaining its v1.6 upstream provenance and local
|
|
|
|
|
source-only rules. This tooling upgrade is not another policy-template adoption.
|
|
|
|
|
- Update [docs/release.md](../release.md) with the selected Go 1.26 patch,
|
|
|
|
|
- [x] Update [docs/release.md](../release.md) with the selected Go 1.26 patch,
|
|
|
|
|
executable setup commands, and v0.3.0 source-pinned upstream references. Keep
|
|
|
|
|
versioning rules in the policy and operations in the runbook.
|
|
|
|
|
- Update the [consumer guide](../consumers/guide.md#go-compatibility) to explain
|
|
|
|
|
- [x] Update the [consumer guide](../consumers/guide.md#go-compatibility) to explain
|
|
|
|
|
the Go 1.26.0 minimum and shared tool-module reason. The current attribution
|
|
|
|
|
of the floor to PromptKit's Go 1.25.5 requirement becomes obsolete.
|
|
|
|
|
- Check contributor navigation and current references affected by the upgrade.
|
|
|
|
|
- [x] Check contributor navigation and current references affected by the upgrade.
|
|
|
|
|
Historical planning records and immutable release notes retain their original
|
|
|
|
|
facts; avoid replacing every historical version string.
|
|
|
|
|
- Apply the [OSS policy](../policy/oss.md) to the actual material scope. Tool use
|
|
|
|
|
- [x] Apply the [OSS policy](../policy/oss.md) to the actual material scope. Tool use
|
|
|
|
|
alone does not require a new attribution entry. Update entries or license links
|
|
|
|
|
if incorporated material or dependency selection changes require it.
|
|
|
|
|
- Explain the Go minimum increase and required consumer action in the next
|
|
|
|
|
CommandKit release note. Select the CommandKit version during release
|
|
|
|
|
preparation under policy, rather than borrowing ReleaseKit's version or
|
|
|
|
|
creating an arbitrarily named release note during this upgrade.
|
|
|
|
|
|
|
|
|
|
### Validation and completion evidence
|
|
|
|
|
|
|
|
|
|
Use the existing validation boundaries rather than adding recurring release gates:
|
|
|
|
|
|
|
|
|
|
- Run the deterministic offline default suite under the selected toolchain,
|
|
|
|
|
- [x] Run the deterministic offline default suite under the selected toolchain,
|
|
|
|
|
covering the public library and native launcher behavior.
|
|
|
|
|
- Exercise the existing opt-in local publication test with the upgraded module
|
|
|
|
|
- [x] Exercise the existing opt-in local publication test with the upgraded module
|
|
|
|
|
selection after cache preparation. It covers a real native bootstrap, exact
|
|
|
|
|
candidate tag publication to a disposable bare repository, one candidate suite,
|
|
|
|
|
clean fixture state, and endpoint-mismatch preflight. Keep it opt-in in normal
|
|
|
|
|
development and publication; this is upgrade evidence, not a new release gate.
|
|
|
|
|
- Inspect production package dependencies to confirm ReleaseKit remains outside
|
|
|
|
|
- [x] Inspect production package dependencies to confirm ReleaseKit remains outside
|
|
|
|
|
the root library and internal adapter import closures. Review module selection
|
|
|
|
|
and CLI version evidence separately from that runtime boundary.
|
|
|
|
|
- Review canonical-document changes, local links/fragments, provenance, and
|
|
|
|
|
- [x] Review canonical-document changes, local links/fragments, provenance, and
|
|
|
|
|
whitespace. Record the actual toolchain, resolved module revision, checks run,
|
|
|
|
|
outcomes, and any qualifications when marking this roadmap implemented.
|
|
|
|
|
|
|
|
|
|
@@ -186,19 +183,64 @@ This work does not publish CommandKit, add hosted delivery, split tooling into a
|
|
|
|
|
second module, or change standard CLI/API semantics. Actual publication and its
|
|
|
|
|
fresh version-matched note remain a separate release-preparation task.
|
|
|
|
|
|
|
|
|
|
## Open Decisions
|
|
|
|
|
## Completion evidence
|
|
|
|
|
|
|
|
|
|
Implemented from `efc5065` using Go 1.26.8 on Linux/amd64. The module now
|
|
|
|
|
contains `go 1.26.0`, the retained CLI tool declaration, and the ReleaseKit
|
|
|
|
|
v0.3.0 requirement/checksums. Module tidy retained that selection. No other
|
|
|
|
|
dependency versions changed and no toolchain directive was added. The downloaded
|
|
|
|
|
module's origin identifies the reviewed `e43df4416e0ed987349b2ea04a2c68c25e552772`
|
|
|
|
|
tag revision; dependency preparation required no checksum repair.
|
|
|
|
|
|
|
|
|
|
Validation completed:
|
|
|
|
|
|
|
|
|
|
- Default suite: `go test -mod=readonly -count=1 ./...` passed with `GOWORK=off`,
|
|
|
|
|
`GOTOOLCHAIN=local`, `GOPROXY=off`, `GONOPROXY=none`, and `GOSUMDB=off`.
|
|
|
|
|
This includes public library and deterministic launcher tests; existing test
|
|
|
|
|
sources were sufficient and unchanged.
|
|
|
|
|
- The existing local publication exercise passed with
|
|
|
|
|
`COMMANDKIT_RELEASE_INTEGRATION=1` and the same offline settings:
|
|
|
|
|
`go test -mod=readonly -count=1 ./scripts -run '^TestReleaseIntegration$' -v`.
|
|
|
|
|
It published only within disposable repositories and proved the candidate,
|
|
|
|
|
single suite execution, clean fixture, and endpoint-mismatch behaviors above.
|
|
|
|
|
- A native CLI was built in ignored `.releasekit/bin/` storage with the launcher's
|
|
|
|
|
host-target and readonly settings. Its `version` output was `releasekit v0.3.0`;
|
|
|
|
|
`go version -m` identified Go 1.26.8 and the module-selected v0.3.0 build.
|
|
|
|
|
- `go list -mod=readonly -deps` for the root package and `internal/cobra` found no
|
|
|
|
|
ReleaseKit, Goldmark, or `golang.org/x/mod` runtime imports. The launcher and
|
|
|
|
|
profile were unchanged. ReleaseKit remains tool-only material; no attribution
|
|
|
|
|
entry or copied source was added under the existing OSS policy.
|
|
|
|
|
- The runbook, release policy's local tool selection, consumer compatibility
|
|
|
|
|
explanation, and contributor navigation now describe the upgrade. The
|
|
|
|
|
release policy remains based on v1.6 at its existing upstream revision.
|
|
|
|
|
Local documentation destinations/fragments, shell snippet syntax, and
|
|
|
|
|
whitespace checks passed.
|
|
|
|
|
|
|
|
|
|
This verifies the upgrade without publishing CommandKit or establishing an
|
|
|
|
|
additional recurring release check. No upstream benchmark or test suite was
|
|
|
|
|
rerun; the evidence concerns CommandKit's selected integration.
|
|
|
|
|
|
|
|
|
|
## Release preparation follow-up
|
|
|
|
|
|
|
|
|
|
The next CommandKit release note must explain the Go minimum increase and
|
|
|
|
|
required consumer action. Its CommandKit version is selected during release
|
|
|
|
|
preparation under policy, with the matching note and footer. That separate
|
|
|
|
|
publication task was not performed or authorized by this upgrade; the current
|
|
|
|
|
consumer guide already explains the compatibility change.
|
|
|
|
|
|
|
|
|
|
## Selected decisions
|
|
|
|
|
|
|
|
|
|
### OD-1: release-validation patch version
|
|
|
|
|
|
|
|
|
|
**Recommendation: select Go 1.26.8.** It is the toolchain available in the
|
|
|
|
|
review environment and used by ReleaseKit v0.3.0's maintainers. Using it avoids
|
|
|
|
|
**Resolved: Go 1.26.8, accepted by the user and implemented.** It is the
|
|
|
|
|
toolchain available in the review environment and used by ReleaseKit v0.3.0's maintainers. Using it avoids
|
|
|
|
|
an additional installation in that environment and benefits from later patch
|
|
|
|
|
updates within the selected Go series. Declare `go 1.26.0` for consumers and
|
|
|
|
|
document 1.26.8 as the runbook's release-toolchain selection. The adopted
|
|
|
|
|
policy permits same-series support to be presumed from this validation; a
|
|
|
|
|
second mandatory run on 1.26.0 is unnecessary absent a concrete concern.
|
|
|
|
|
|
|
|
|
|
**Alternative: select Go 1.26.0.** It validates directly at the consumer floor
|
|
|
|
|
**Alternative considered: Go 1.26.0.** It validates directly at the consumer floor
|
|
|
|
|
and makes the minimum and release toolchain identical initially. It requires
|
|
|
|
|
installing that patch in the reviewed environment and forgoes subsequent patch
|
|
|
|
|
updates. It is viable if direct minimum-toolchain validation is preferred, but
|
|
|
|
|
|
