ChronVer

Versioning for the rest of us

Format


YYYY.MM.DD[.CHANGESET][-FEATURE|-break]

Examples

Version Description
2025.07.21 Released July 21st, 2025
2025.07.21.1 First hotfix today
2025.07.21.3 Third change today
2025.07.21-feature Feature branch made today
2025.07.21.1-feature Feature branch with changeset
2025.07.21.1-break Breaking change

FAQ

Why not just use dates?

ChronVer is dates, but with a structured format that supports multiple releases per day, feature branches, and breaking change indicators.

What about semantic compatibility?

ChronVer can indicate breaking changes with the -break suffix. For situations where semantic versioning is crucial, stick with SemVer.

How do I migrate from SemVer?
  1. Choose your first ChronVer date (usually next release)
  2. Update your build tools to use chronver increment
  3. Update documentation to explain the new format
  4. Consider keeping a mapping in your CHANGELOG
Can I use both ChronVer and SemVer?

Absolutely! Here's how your project could use ChronVer for releases and SemVer for API versions:


{
  "apiVersion": "v2.1.0",
  "version": "2024.07.19.1"
}

Easy-peasy.

Comparison with SemVer

Aspect ChronVer SemVer
Clarity Immediately shows when released Requires lookup
Planning Aligns with calendar schedules Feature-driven
Communication "The April release" "Version 3.2.1"
Sorting Chronological by default Arbitrary without context
Compatibility Time-based breaking changes API contract based
Best for Time-sensitive releases Library compatibility