diff --git a/docs/roadmap/releasekit.md b/docs/roadmap/releasekit.md index bb48280..a6780f0 100644 --- a/docs/roadmap/releasekit.md +++ b/docs/roadmap/releasekit.md @@ -47,6 +47,15 @@ best effort. ReleaseKit's other optional checks, including formatting, Markdown, module-distribution, and file-size checks, remain unselected unless a separate decision establishes a distinct need for them. +Declare `gitea.maximumdirect.net/eric/ReleaseKit/cmd/releasekit` with a +`go.mod` `tool` directive and pin its module at v0.2.0, with resolved checksums +in `go.sum`. The release-tool build uses that module selection; there is no +separate executable-version pin. This adds release-tool dependencies to +ConfigKit's module graph without importing ReleaseKit into library code or +adding a runtime API. Review the resulting module changes and license +treatment under the [OSS policy](../policy/oss.md); tooling use alone does not +require an attribution entry. + At each release preparation, select the newest Go version available in the development environment and advance ConfigKit's `go.mod` `go` directive to that version. This deliberately raises ConfigKit's minimum Go version for @@ -62,6 +71,14 @@ 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 ` +first line, while aligning release policy with the guards that actually run. +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 owns generic candidate guards, test and compile coordination, tag creation, publication, and push recovery. ConfigKit owns version selection, compatibility review, note content, its selected validation and support @@ -70,7 +87,9 @@ release process adds no ConfigKit public API or runtime use of ReleaseKit. ## Changes from the baseline -- Add the minimal profile and a documented, versioned tool-preparation method. +- 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 select the newest Go available in the development environment, advance `go.mod`, and build ReleaseKit with that same Go executable. Keep the selected release command small and do not re-create @@ -79,7 +98,8 @@ release process adds no ConfigKit public API or runtime use of ReleaseKit. [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, and ReleaseKit's failure states. Preserve ConfigKit's + 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 @@ -99,47 +119,3 @@ release process adds no ConfigKit public API or runtime use of ReleaseKit. Historical tags and release notes remain unchanged. This adoption work does not itself authorize publication of a ConfigKit version. - -## Open Decisions - -### How should ConfigKit pin and acquire ReleaseKit? - -**Recommendation:** Use a separately installed ReleaseKit executable pinned to -v0.2.0 for the first migration, built with the Go version selected during -release preparation. Document acquisition before offline validation. ConfigKit -has no hosted-delivery workflow to coordinate with a CI tool pin, so this -keeps ReleaseKit and its tool dependencies out of ConfigKit's library module -graph. The [OSS policy](../policy/oss.md) does not require an attribution entry -merely for using a development tool. - -**Viable alternative:** Declare ReleaseKit in ConfigKit's `go.mod` and use its -module-selected tooling convention. This gives local publication and any future -tag-triggered delivery one version declaration, but adds tool dependencies to -the library's module graph and requires dependency and attribution review. - -### Should ConfigKit keep its stricter local publication guards? - -**Recommendation:** Adopt ReleaseKit's note-heading rule and exact -`expected_push_url` check, while continuing to write notes as -`# ConfigKit `. Update policy wording to match the actual automated -guards. ReleaseKit checks the effective publication endpoint and queries that -endpoint for remote state; retaining a second ConfigKit-specific fetch-URL and -exact-heading checker would preserve local release machinery for little added -value. - -**Viable alternative:** Retain small product checks for ConfigKit's exact -first-line title and both configured fetch and push URLs. This preserves the -current local policy literally, but makes ConfigKit continue owning and testing -release-specific checks alongside ReleaseKit's standard guards. - -### Must the release command list skipped filesystem tests? - -**Recommendation:** Treat per-test skip output as optional diagnostic detail -and revise the runbook's statement that the release checker reports it. -ReleaseKit's single standard suite is not verbose, while failed tests still -block publication. This avoids an extra test run solely for output. - -**Viable alternative:** Ask ReleaseKit for a supported verbosity selection -within its one base test invocation. This preserves the current skip display -without duplicating the suite, but expands the shared API and may add output -that other consumers do not need.