Article illustration 1

In the perennial tension between semantic versioning's compatibility guarantees and calendar versioning's temporal clarity, a new contender emerges: ScalVer (GitHub). This specification reimagines versioning as <MAJOR>.<DATE>.<PATCH>, where the DATE segment dynamically expands from YYYY to YYYYMM to YYYYMMDD within a single major version line—a deliberate evolution addressing critical gaps in modern release management.

Why Calendar-Aware Versioning Matters

Traditional SemVer excels at signaling breaking changes but obscures release timelines. CalVer prioritizes timestamps but sacrifices compatibility semantics. ScalVer bridges this divide:
- SemVer-Compatible Syntax: Every ScalVer tag (1.202503.5) is valid SemVer, leveraging existing ecosystem tooling (npm, Cargo, Maven).
- Date-Only-Grows (DOG) Rule: The DATE segment expands (e.g., 2025 → 202503 for March 2025) but never shrinks within a major version, preserving sort order.
- Cadence Flexibility: Projects can shift release frequency—from yearly to monthly to daily—without breaking version comparisons.

Core Mechanics: More Than Just a Date Stamp

1.20250301.7  → MAJOR=1, DATE=20250301 (March 1, 2025), PATCH=7
  • MAJOR: Incremented for breaking changes or when resetting DATE precision (e.g., jumping from daily back to yearly releases).
  • DATE: Expands left-padded (YYYY → YYYYMM → YYYYMMDD) as release cadence accelerates. Resets to initial width after MAJOR bumps.
  • PATCH: Standard patch counter for backward-compatible fixes within the same DATE window.

Real-World Implications

Cadence Example Tag Meaning
Yearly 1.2025.3 Fourth patch of 2025
Monthly 1.202503.2 Third March 2025 release
Daily 1.20250301.7 Eighth release on Mar 1

Toolchain Resilience: Because ScalVer repurposes SemVer's MINOR field as DATE, dependency managers interpret ^1.2025.0 as "compatible with all 1.xx.x releases"—no parser modifications needed.

Migration Playbook:
1. Choose initial DATE precision (e.g., YYYYMM for monthly releases).
2. Compare current DATE against legacy MINOR values to avoid collisions.
3. Increment MAJOR only when resetting DATE width or introducing breaking changes.

The Y10K Question and Edge Cases

ScalVer's grammar enforces 4-digit years for ISO-8601 compliance but remains logically sound beyond 9999. While shrinking DATE precision (e.g., from daily YYYYMMDD to monthly YYYYMM) within a major version is forbidden, a MAJOR bump resets this constraint, allowing cadence adjustments.

Why This Matters for Modern Development

As release cycles accelerate—especially in DevOps and SaaS environments—ScalVer offers a structured path to embed temporal context without fracturing ecosystem tooling. By decoupling cadence from compatibility semantics, it empowers teams to version prototypes (0.2025.0), stable products (1.2025.0), and hyper-iterative services (1.20250301.15) under one coherent scheme.

Projects like PlantUML have pioneered similar approaches, but ScalVer's formal specification and SemVer compliance could cement it as the missing link between rigorous compatibility and agile release rhythms. For teams drowning in ambiguous version numbers, this might just be the lifeline they've needed.