From 7afc0de092f9b6bbf35955c0b20b0ebbc73d1abb Mon Sep 17 00:00:00 2001 From: Eric Rakestraw Date: Wed, 7 Oct 2026 17:02:05 +0000 Subject: [PATCH] Accept the module-selected tooling ADR --- docs/adr/0004-module-selected-tooling.md | 68 ++++++++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 docs/adr/0004-module-selected-tooling.md diff --git a/docs/adr/0004-module-selected-tooling.md b/docs/adr/0004-module-selected-tooling.md new file mode 100644 index 0000000..6040c63 --- /dev/null +++ b/docs/adr/0004-module-selected-tooling.md @@ -0,0 +1,68 @@ +# ADR 0004: Select release tooling from the released application's module configuration + +## Status + +Accepted. + +## Date + +2026-10-07 + +## Context + +Applications can declare ReleaseKit as a Go module dependency and use that +selection to build their local release tool. A separate CI version pin creates +a second declaration that maintainers must coordinate during upgrades. The two +paths can then use different ReleaseKit versions for the same release. + +Hosted delivery runs after source publication and may be retried for an older +release. It needs a stable source for tool-version selection associated with +that release. [ADR 0002](0002-routine-releases.md) prioritizes reducing repeated +configuration and routine release decisions. + +## Decision + +For applications that declare ReleaseKit as a module dependency, the standard +integration selects the tool through the application's module configuration. +Local publication uses the candidate's module configuration. CI delivery uses +the released source's module configuration. Both paths follow the same +module-based selection approach. + +CI verifies the triggering tag and commit and checks out that source before +resolving and building the release tool. Delivery retries use the same released +source for tool selection. The application maintains its ReleaseKit dependency +as the shared version declaration for these operations. + +Tool bootstrap and dependency preparation remain separate from offline +validation and builds. The CI integration supplies the event, environment, and +credentials; the application profile supplies product and delivery settings. +Source publication and hosted delivery retain their separate outcomes. + +Consumers using a separately installed tool and ReleaseKit's own source +bootstrap remain supported use cases. Adoption guidance describes the +appropriate bootstrap for each integration. + +## Alternatives considered + +- An independent CI version pin makes tool selection explicit in the workflow + and requires maintainers to coordinate it with the application's dependency. +- Selecting from the current default branch follows ongoing dependency + updates and allows delivery retries for an older release to select a newer + tool. + +## Consequences + +Applications using the standard module-based integration update one dependency +declaration for local publication and CI delivery. Tool selection follows the +released source when delivery is retried, preserving the release's dependency +choice as the application evolves. + +CI must establish the released checkout before tool bootstrap. Its environment +must provide a compatible Go toolchain and access to the dependencies needed +to build the selected tool. Retrying delivery for an older release retains +those preparation requirements. + +Maintained templates and adoption guidance must preserve this selection order. +Verification should exercise a dependency-version change and selection from +the triggering release's source. Exact commands and bootstrap mechanics belong +in the maintained integration guidance and examples.