ADR 0013: Independent starter release lifecycles
Status: Accepted
Context
ADR 0012 established that external-system integrations do not belong in the
standard-library-first core module. Its initial repository table grouped
OpenTelemetry under starter-observability and OAuth2/OIDC under
starter-security. Implementation and acceptance exposed different dependency,
security, and compatibility lifecycles inside both proposed groups:
- OpenTelemetry adapters evolve with the OpenTelemetry API and provider model;
- OAuth2 client credentials depend on outbound HTTP token acquisition policy;
- OIDC resource servers depend on discovery, JWKS, JWT, and identity-provider interoperability;
- gRPC, WebSocket, and Kafka each require a different real-system matrix.
Keeping unrelated integrations together would reproduce the module-graph and release coupling that the multi-repository migration is intended to remove.
Decision
Every production starter is an independently versioned Go module when it owns a distinct external dependency or interoperability lifecycle. The initial repositories are:
spice-framework/starter-smtp;spice-framework/starter-postgres;spice-framework/starter-mysql;spice-framework/starter-redis;spice-framework/starter-otel;spice-framework/starter-oauth2client;spice-framework/starter-oidc;spice-framework/starter-websocket;spice-framework/starter-grpc;spice-framework/starter-kafka.
Each module depends only on public Spice contracts, declares a strict minimum and current compatible core revision, owns its direct dependency review and vendor graph, and proves its relevant real-system behavior. Repositories are not combined merely to reduce repository count.
The spice-framework/development compatibility catalog is the authoritative
tested ecosystem inventory. It coordinates workspaces and verification but is
not a package resolver or BOM. Applications continue to select exact versions
through ordinary go.mod, go.sum, MVS, and optional go.work files.
Core may retain dependency-free portable starter metadata and static auto-configuration contracts. It does not retain a compatibility forwarding package for an extracted external client. An external starter becomes authoritative only after filtered history, standalone verification, hosted acceptance, and a durable organization repository are green.
Consequences
Core consumers no longer select client libraries they do not use. A security or compatibility release in one starter does not force unrelated starter releases. Each repository has a smaller and faster local feedback loop and an acceptance matrix matched to its system.
There are more repositories to govern. That cost is controlled by reusable organization workflows, identical quality contracts, machine-readable compatibility metadata, and the development catalog. Cross-starter features compose through public Spice interfaces rather than private repository access or lockstep versions.
This decision refines the starter names in ADR 0012; its foundation, editor, reference-application, module, and dependency-tier decisions remain in force.