# 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.