64 lines
2.6 KiB
Markdown
64 lines
2.6 KiB
Markdown
# 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.
|