diff --git a/docs/roadmap/v0.2.0.md b/docs/roadmap/v0.2.0.md index 83abd75..6d836a9 100644 --- a/docs/roadmap/v0.2.0.md +++ b/docs/roadmap/v0.2.0.md @@ -62,3 +62,135 @@ installed tool remain supported use cases. Completion should leave downstream maintainers with one ReleaseKit dependency update for this integration and a maintained template they can adopt directly. + +## 2. Select one base test invocation, including race testing + +### Rationale and current baseline + +ReleaseKit always runs its standard offline Go suite before additional product +checks. ConfigKit selects race-enabled testing for its release validation. +Expressing that selection as an additional check would execute the suite twice +and leave the application coordinating shared validation mechanics. + +A small declarative selection lets consumers retain their chosen validation +while ReleaseKit owns the procedure and runs the suite once. + +### Target end state + +The public Go API and profile support selecting race testing for the single +base Go test invocation. With no selection, the current default applies. +`Check` and `Publish`, including their CLI forms, use the same selection. + +ReleaseKit constructs the invocation and owns candidate capture, full-suite +scope, offline execution, ordering, and failure reporting. Additional product +checks remain available after shared validation. Selecting race testing reports +unavailable prerequisites clearly and preserves the selected validation. + +### Work needed + +- Add compact validation options to the facade and profile, and carry them + through both candidate-check and publication paths. +- Extend shared Go invocation handling to apply race selection to the base + suite while preserving its offline environment and native test behavior. +- Update consumer guidance and verify default behavior, one selected suite run, + consistent API/CLI behavior, and propagation of validation failures. + +Completion should let ConfigKit select its race-enabled suite once and remove +the corresponding consumer-owned test invocation. + +## 3. Offer a separate full vet pass + +### Rationale and current baseline + +ConfigKit selects a full `go vet` pass in addition to its test suite. ReleaseKit +currently relies on test-time vet unless a consumer supplies an additional +command. That leaves consumers coordinating vet coverage and repeated work. + +### Target end state + +A public API and profile option selects a separate full vet pass within shared +candidate validation. ReleaseKit automatically omits test-time vet when that +pass is selected. The base suite runs once, followed by the selected vet pass, +with failures reported through the ordinary check and publication flow. + +The option preserves current defaults for consumers that leave it unset. +ReleaseKit owns the offline command and its coordination with base testing. + +### Work needed + +- Add the full-vet selection to shared validation configuration and execution. +- Coordinate the base test invocation with the separate pass so consumers + express the desired coverage once. +- Document the selection and verify ordering, test-time vet omission, failure + handling, and unchanged default behavior through the shared validation path. + +Completion should replace ConfigKit's separate vet command and manual +test-time vet setting with one declarative choice. + +## 4. Verify package compilation for selected targets + +### Rationale and current baseline + +ReleaseKit's existing build declaration selects executable artifacts and their +delivery. ConfigKit is a source-only library that checks package compilation +for Linux amd64 and arm64. Its current release script owns the cross-target +build loop even though the underlying mechanics are shared across consumers. + +### Target end state + +The public API and profile can declare optional package-compilation targets +independently of executable artifacts. ReleaseKit compiles the module's packages +for those targets within candidate validation, after the selected test and vet +work. `Check` and `Publish` share this behavior and report compilation failures +through their existing outcomes. + +A source-only library retains page-only delivery. Package-compilation checks +require no binary name, version smoke command, or artifact manifest. Successful +compilation establishes build compatibility; execution on a target remains a +separate concern. Consumers select targets for their support commitments. + +### Work needed + +- Add a package-compilation target declaration to validation configuration, + distinct from the existing artifact build specification. +- Reuse internal Go environment and target handling for offline compilation, + replacing consumer-owned loops and preserving one base test execution. +- Document the distinction between compatibility checks and deliverables, and + verify selected-target compilation, failure reporting, and unchanged + source-only delivery behavior. + +Completion should let ConfigKit declare its two Linux targets and remove its +release-specific compilation loop. + +## 5. Check an optional expected publication endpoint + +### Rationale and current baseline + +ReleaseKit resolves and captures the selected remote's push endpoint and +rechecks it during publication. ConfigKit additionally declares an expected +authoritative destination in its release script. Retaining that expectation +outside ReleaseKit would duplicate destination-resolution work. + +### Target end state + +An optional public API and profile setting declares the expected publication +destination. `Publish` compares it with the resolved push endpoint before +candidate validation and publication. A mismatch produces a clear failure. +The existing captured-endpoint, recheck, and recovery machinery continues to +govern the operation. + +The expectation applies to the publication destination. Fetch configuration +retains its existing semantics, and `Check` retains its local-only behavior. +Consumers that omit the expectation keep the current remote-selection model. + +### Work needed + +- Add the optional expectation to the facade and profile and compare it at + the existing publication endpoint-resolution boundary. +- Reuse captured-endpoint handling and define the destination-comparison + semantics in GoDoc and consumer guidance. +- Verify matching, mismatching, and omitted expectations, including resolved + Git URL behavior, while preserving existing recheck and recovery coverage. + +Completion should let consumers declare the intended push destination without +maintaining their own publication preflight logic.