197 lines
9.2 KiB
Markdown
197 lines
9.2 KiB
Markdown
# ReleaseKit v0.2.0 roadmap
|
|
|
|
Status: Draft scope for the next release.
|
|
|
|
This roadmap catalogs improvements to ReleaseKit v0.1.0. Each item records its
|
|
rationale, target state, and scope of work. A staged implementation plan will
|
|
follow once the release scope is finalized.
|
|
|
|
The priorities in [ADR 0002](../adr/0002-routine-releases.md) guide this work:
|
|
minimize application-owned release code, duplicated mechanics, and routine
|
|
developer decisions through a standard, minimal API.
|
|
|
|
## 1. Use the application's module-selected ReleaseKit version in CI
|
|
|
|
### Rationale and current baseline
|
|
|
|
The maintained [CI template](../../examples/woodpecker/tag-delivery.yml) selects
|
|
ReleaseKit through a separate `RELEASEKIT_VERSION` value and invokes its command
|
|
with an explicit `@version`. The [adoption guidance](../consumers/delivery.md#woodpecker-tag-workflows)
|
|
instructs consumers to maintain that workflow pin.
|
|
|
|
Audita demonstrates the resulting duplication: its local release wrapper builds
|
|
ReleaseKit using the application's module dependencies, while CI independently
|
|
selects ReleaseKit v0.1.0. A dependency upgrade can leave CI using an older tool.
|
|
Maintainers must remember to coordinate both declarations.
|
|
|
|
Using the application's module-selected version for both paths gives upgrades
|
|
one dependency declaration and keeps local publication and CI delivery aligned.
|
|
|
|
### Target end state
|
|
|
|
For applications that declare ReleaseKit as a module dependency, the standard
|
|
CI integration uses the ReleaseKit version selected by the released source's
|
|
module configuration. The workflow verifies the triggering tag and commit and
|
|
checks out that source before resolving and building the release tool.
|
|
|
|
Local publication and CI delivery use the same module-based selection approach.
|
|
Updating the application's ReleaseKit dependency updates both paths. The
|
|
consumer workflow supplies the CI event, environment, and credentials; the
|
|
application profile continues to supply product and delivery settings.
|
|
|
|
Tool bootstrap and dependency preparation remain distinct from offline
|
|
validation and builds. Source publication and hosted delivery retain separate
|
|
outcomes. ReleaseKit's own source bootstrap and consumers using a separately
|
|
installed tool remain supported use cases.
|
|
|
|
### Work needed
|
|
|
|
- Revise the maintained CI template to establish the tagged checkout before
|
|
selecting and building the module's ReleaseKit command. Remove the separate
|
|
version setting from this module-based integration and keep bootstrap logic
|
|
small and reusable.
|
|
- Update adoption and upgrade guidance to explain module-based selection,
|
|
compatible Go environments, dependency preparation, and migration from the
|
|
existing workflow pin. Explain the applicable bootstrap for consumers that
|
|
use a separately installed tool.
|
|
- Adapt workflow verification to exercise tool selection from the tagged
|
|
module configuration, including a dependency-version change, while preserving
|
|
tag/commit checks and existing source-only and binary delivery behavior.
|
|
- Apply the revised integration to Audita as the first consumer migration and
|
|
confirm that its local wrapper and CI use the same module-selected tool.
|
|
|
|
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.
|