From b240e3cfa94b4fba5cb022d1e6ce05e48d9965e2 Mon Sep 17 00:00:00 2001 From: Eric Rakestraw Date: Tue, 6 Oct 2026 16:02:34 +0000 Subject: [PATCH] Record the priorities for routine releases --- docs/adr/0002-routine-releases.md | 63 +++++++++++++++++++++++++++++++ docs/development.md | 3 ++ 2 files changed, 66 insertions(+) create mode 100644 docs/adr/0002-routine-releases.md diff --git a/docs/adr/0002-routine-releases.md b/docs/adr/0002-routine-releases.md new file mode 100644 index 0000000..ef52ede --- /dev/null +++ b/docs/adr/0002-routine-releases.md @@ -0,0 +1,63 @@ +# ADR 0002: Make routine releases a shared responsibility + +## Status + +Accepted. + +## Date + +2026-10-06 + +## Context + +Applications in the suite repeat release code and require developers to manage +similar release decisions. ReleaseKit centralizes this work. Its value depends +on reducing application maintenance and the time developers spend on releases. + +Build specialization, environment standardization, and detailed inspection can +serve particular consumers. Supporting them can also expand the API, +configuration, and release knowledge each application must maintain. ReleaseKit +needs a clear priority for evaluating these tradeoffs. + +## Decision + +ReleaseKit provides a standard, minimal API for routine releases. It minimizes +application-owned release code, duplication across applications, and the +decisions application developers must make. + +ReleaseKit owns the common release procedure and sensible defaults. Applications +supply product facts, compatibility requirements, and product-specific checks. + +Hardware-specific build options, strict build reproducibility, extensive build +inspection, and comparable specialization are non-goals to the extent that +supporting them conflicts with these primary goals. + +Evaluate proposed capabilities by their effect on ordinary application +integration: the code applications maintain, the configuration they supply, and +the release decisions developers make. A demonstrated consumer need informs +that assessment; the selected approach must preserve the routine release model. + +## Alternatives considered + +- A broadly configurable release toolkit gives applications control over build + and release mechanics. Applications then own more composition code and + configuration decisions. +- A tightly standardized build environment prioritizes reproducibility and + detailed build records. It adds environment maintenance and coordination + responsibilities across applications. + +The selected approach evaluates those capabilities by the application work and +developer effort they save. + +## Consequences + +Common release operations belong behind reusable orchestration. Shared defaults +reduce configuration and routine decisions. ReleaseKit can absorb internal +complexity when doing so keeps application integration small and maintainable. + +New options carry implementation, maintenance, and decision costs. Consumer +needs justify evaluating an option; its adoption must support the primary goals. + +The [architecture policy](../policy/architecture.md) owns current architectural +constraints. [ADR 0001](0001-public-facade.md) records the facade boundaries. +GoDoc owns exact API contracts. diff --git a/docs/development.md b/docs/development.md index c675def..3163933 100644 --- a/docs/development.md +++ b/docs/development.md @@ -12,6 +12,9 @@ The [architecture policy](policy/architecture.md) governs development boundaries [documentation policy](policy/documentation.md#canonical-ownership) owns the documentation topic map. +[ADR 0002](adr/0002-routine-releases.md) records the priorities and non-goals +behind ReleaseKit's standard, minimal API for routine releases. + ## Policy Reading Guide | Policy | Read before… |