2.6 KiB
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 owns current architectural constraints. ADR 0001 records the facade boundaries. GoDoc owns exact API contracts.