Problem / why
The current docs (e.g. docs/src/content/docs/versioning.md) describe per-component
versioning as a reserved, behavior-free shape. Once schema-2 ships, the docs must describe the
real schema_version 2 components: model: per-component version / tag / promotion behavior,
the additive opt-in-by-format adoption (write a schema-2 manifest; schema-1 keeps working),
the optional cascade upgrade-manifest helper, and the single-service-is-one-component
framing.
Scope (firm intent)
- Update versioning and manifest docs to cover the schema-2
components: block, per-component
version lines and tag prefixes, per-component triggering, per-component promotion / hotfix /
rollback / release, environment subsets, and the opt-in-by-format adoption path.
- Document that schema 1 and schema 2 coexist, schema 1 runs unchanged forever, and there is
no forced migration; mention cascade upgrade-manifest as the optional convert helper.
- Remove the reserved-shape language now that the shape carries behavior.
- State plainly that cross-component dependencies are out of scope and the
external /
notify mechanism is the coordination path.
Files / areas touched
docs/src/content/docs/ (versioning and manifest pages).
Tests and coverage required
- Docs build / link check passes.
Acceptance criteria
- Docs describe the shipped schema-2 model with no remaining reserved-shape language.
- Docs make the additive, opt-in-by-format adoption explicit (no forced migration).
Dependencies
Blocked by the monorepo: independent hotfix and release milestone (so docs reflect the
complete lifecycle).
Problem / why
The current docs (e.g.
docs/src/content/docs/versioning.md) describe per-componentversioning as a reserved, behavior-free shape. Once schema-2 ships, the docs must describe the
real
schema_version 2components:model: per-component version / tag / promotion behavior,the additive opt-in-by-format adoption (write a schema-2 manifest; schema-1 keeps working),
the optional
cascade upgrade-manifesthelper, and the single-service-is-one-componentframing.
Scope (firm intent)
components:block, per-componentversion lines and tag prefixes, per-component triggering, per-component promotion / hotfix /
rollback / release, environment subsets, and the opt-in-by-format adoption path.
no forced migration; mention
cascade upgrade-manifestas the optional convert helper.external/notifymechanism is the coordination path.Files / areas touched
docs/src/content/docs/(versioning and manifest pages).Tests and coverage required
Acceptance criteria
Dependencies
Blocked by the
monorepo: independent hotfix and releasemilestone (so docs reflect thecomplete lifecycle).