DR-011: CalVer for Documentation, SemVer for Code
Status
- [x] Accepted
- [ ] Proposed
- [ ] Rejected
- [ ] Deprecated
- [ ] Superseded
Date: 2024-12-05
Context
Different artifact types have different upgrade semantics. Code artifacts need API compatibility signals. Documentation releases are time-based.
Problem: How to communicate appropriate version semantics for different module types?
Decision
Mixed versioning strategy based on artifact type and release semantics.
Versioning Schemes:
- SemVer (API compatibility):
- Modules:
r2r-cli,ext-eac,eac-commands,eac-mcp-commands,implicit-r2r-cli,r2r-installer,vscode-ext-commit - Format:
MAJOR.MINOR.PATCH - Breaking changes → MAJOR bump
-
Communicates upgrade safety
-
CalVer (time-based releases):
- Modules:
docs,books,release-docs,r2r-eac-bundle - Format:
YYYY.MMorYYYY.0M - Independent documentation updates
-
No API compatibility concerns
-
Implicit (library versioning):
- Modules:
eac-core,eac-specs - Versioned via dependent modules
- No independent releases
-
Reduces version noise
-
No Versioning (infrastructure):
- Modules:
repository,templates,github, container base images - Not independently released
- Development utilities
Release Bundles:
- CalVer-versioned aggregates
- Combine multiple module versions
- Format:
r2r-(r2r_version) ∞ eac-(eac_version) - Example:
r2r-(0.0.24) ∞ eac-(0.0.15)
Consequences
Positive: Clear semantics, independent cadences, appropriate signaling, flexible releases, reduced version noise
Negative: Mixed schemes complexity, version mapping overhead, documentation needed
Alternatives Considered
- SemVer Only: Rejected - poor semantics for time-based documentation, forces unnecessary major bumps
- CalVer Only: Rejected - no API compatibility signals, upgrade uncertainty for code
- Single Unified Version: Rejected - forces coupled releases, limits flexibility
Related Decisions
Tutorials | How-to Guides | Explanation | Reference
You are here: Reference — information-oriented technical descriptions of the system.