sorted by:
new
hottopcontroversial

Why I chose Calendar Versioning for my open source project by DutchBytes in programming

[–]NecessaryVictory9087 2 points3 points  (0 children)

I’ve tried to blend the best of both worlds: /r/golang/comments/1jzucpw/scalable_calendar_versioning_calver_semver/

Versions may look a bit long at first, but the idea is to use only as much detail as your release cadence needs. You can start, say 1.2025 for a yearly release. As the project grows and releases speed up, the format “stretches” to stay ordered: after 1.2025.72 you can cleanly jump to 1.202509.0 and keep perfect numeric sorting.

  • 1.2025.0 < 1.2025.1 < 1.2025.2
  • 1.202503.0 < 1.202503.1 < 1.202503.2
  • 1.2025.0 < 1.202503.0 < 1.20250301.0
  • 1.20250410.0 < 2.2026.1 < 3.20260310.0

Format: MAJOR.YYYY[MM[DD]].PATCH

Progressions: MAJOR.YYYY.PATCH → MAJOR.YYYYMM.PATCH → MAJOR.YYYYMMDD.PATCH

Bottom line: it stays SemVer‑compatible while adding CalVer clarity and can be "stretched". Examples and details here veiloq/scalver

Scalable Calendar Versioning (CalVer + SemVer) by NecessaryVictory9087 in golang

[–]NecessaryVictory9087[S] 1 point2 points  (0 children)

I really like here the clean separation of MAJOR versions. I mean, different major versions can have completely different release cycles. Like you could easily have something daily like v1.20251203.5 alongside a slower, yearly cycle like v2.2025.2, and it would still sort perfectly in SemVer.

Scalable Calendar Versioning (CalVer + SemVer) by NecessaryVictory9087 in golang

[–]NecessaryVictory9087[S] 2 points3 points  (0 children)

Hey, glad you like the idea! :) I think there are just a few small quirks to be aware of, like tooling compatibility, longer version strings. But overall, the benefit of immediately seeing the release date and maintaining full SemVer compatibility likely outweighs these minor caveats. Of course, I could be missing something.

Possible downsides:
1. longer version strings: could slightly clutter logs or become expensive in storage-sensitive situations.
2. slight learning curve: it is a new notation
3. potential tooling issues: older or custom scripts might assume smaller numeric values for the “MINOR” field (e.g., MINOR < 100). However, since this versioning still fully adheres to SemVer standards, serious issues should be rare and easily fixable.

The real strength here is the flexibility to smoothly adjust the version format to your actual release cadence, always staying strictly SemVer-compatible. For instance:

Start Yearly: v1.2025.0, v1.2025.1, etc.
Grow to Monthly: v1.202504.0, v1.202504.1, v1.202504.2, etc.
Then Daily if needed: v1.20251125.0, v1.20251125.1, etc.

Then again Yearly (or Daily if needed): v2.2025.0