Calendar Versioning (CalVer)
Calendar Versioning (CalVer) ties version identifiers to release dates rather than semantic compatibility signals. Common formats: YYYY.MM.DD (Ubuntu: 24.04), YYYY.MM (pip, some Python packages), YYYY.0N (pip: 23.1, 23.2). CalVer communicates when a release occurred, which is useful for time-sensitive software (operating systems, security tools) where the age of a version carries meaning.
Why it matters in practice
CalVer provides implicit freshness information but no compatibility signal — 24.04 being newer than 23.10 says nothing about breaking changes. This is acceptable for end-user software where "keep it updated" is the primary guidance, but problematic for libraries and APIs where consumers need to know whether a version bump is safe to apply automatically. Some projects combine CalVer with compatibility signalling (Ubuntu's LTS vs non-LTS releases), but this requires documentation conventions rather than the version number itself.
Common mistakes
- •Using CalVer for a library or API where consumers need compatibility signals — without MAJOR/MINOR/PATCH, consumers cannot determine safe version ranges for dependency management.
- •Assuming CalVer implies more frequent releases — the versioning scheme does not mandate release cadence.
- •Not documenting breaking changes explicitly — CalVer does not signal them, so release notes must compensate.