Why CalVer beats semantic versioning

A take by @mahmoud

Why CalVer beats semantic versioning – Mahmoud Hashemi 0:00 / 4:14

Remember, these all turn into arbitrary numbers at the end of the day, and so the semantics break down pretty soon after you exit the infancy of a software project.

In a nutshell
  • CalVer beats semantic versioning because as a library maintainer, I can literally just slap the current date on it.
  • Realistically, for mature software it has too large of a surface area to police.
  • Serious software projects use calendar versioning.
506 words · 2 min read

The unspecified semantic

CalVer stands for calendar versioning, and it beats semantic versioning because as a library maintainer, I can literally just slap the current date on it, and I don't need to worry about the quote-unquote "semantics" of semantic versioning. Semantic versioning, supposedly, when you break (for some definition of break) an interface, you have to create a major version. I think this is originally supposed to signal to the user of your software that it's a big upgrade or they need to be careful about the upgrade. And that's the unspecified semantic.

Realistically, for mature software, it has too large of a surface area to police. And on top of that, if it's mature enough, you probably have a schedule. If you have a lot of users and stuff like that, then you are going to deprecate things. You're not just going to remove things and break the library. You're going to actually deprecate.

You're not just going to remove things and break the library. You're going to actually deprecate.

A mature schedule

Calendar versioning is a lot easier from a maintainer perspective, and then from a user perspective, it's easier because you can just look at your libraries or your version numbers and see how old they are. And if you have parallel software, as Apple noticed, they have their watchOS, their iOS, their macOS. They were all different random numbers in the teens and 20s. And you had to have this mental mapping of which ones overlap.

Realistically, they have a WWDC every year. They have a mature schedule, and now you can look at the version numbers, you can see watchOS 26 probably works well with macOS 26. iOS 26, you don't have to keep some arbitrary mapping of watchOS 14 was contemporaneous with macOS 21 or whatever. That's stupid, waste of time, doesn't help anyone.

That's stupid, waste of time, doesn't help anyone.

Serious software projects

So serious software projects use calendar versioning, and if you're just some tiny little infancy project, then your version number probably doesn't need to be overthought and analyzed for if it breaks some interface. Just slap a number on there and maintain a change log.

Just slap a number on there and maintain a change log.

That's my perspective as the maintainer of calver.org, the premier alternative to SemVer. You can find the short list of serious software projects that use calendar versioning on calver.org. Just off the top of my head, Ubuntu was a major inspiration when I published it back in 2016. Now it's 2026, 10 years later, and Apple and Nvidia have both adopted it. So I'm feeling pretty good about calendar versioning being a serious entrant in the versioning world. All my libraries use it, some of them are somewhat popular. And of course also, I worked at Stripe, and Stripe's API versioning uses it as well. Check out calver.org for a more complete list, but it's a list that's constantly growing. All increasingly large, serious projects.

See also

v1 · Oct 2026