See CalVer. The date is definitely helpful for something with fairly stable APIs where breaking changes aren’t really happening.

Perfect for things like Ubuntu, pytz, and ca-certificates.

Less for something like a library who’s API could change and break your implementation.

CalVer is useful for Ubuntu. But not because it's stable, just the opposite:

It's useful for Ubuntu, because each Ubuntu release is a hodgepodge of lots of unrelated updates. Some will be breaking, some will be fine.

Also for systems relying on continuous delivery in some form, like websites and web apps and SaaS. Because as a user you don't actually have a choice to use an update or stay on an old one.

Considering most places I've worked at just bump the minor number in perpetuity, a date-based version conveys a bit more info. Also so much easier to know when it's going out if you have a release cycle (e.g. you don't have to guess what date 3.12354.0 is going to prod, you would know it already from a version like 2021.12.25).

For binaries, I agree. For libs, I prefer semver

Not the git hashcode?

Semver and calver are sequential, so you can easily sort them and compare versions in terms of age. So you would know that jumping from 1.8 to 3.0 for example could be quite large.

You can't do the same with git commit hashes because you can't sort them based on the hash alone. I have no idea how to compare deadbeef and cafebabe without checking the code itself.