Yes - https://0ver.org/about.html

“ZeroVer is satire, please do not use it”

But why is it satire? It makes a lot of sense for projects that don't want to commit to a stable API.

For projects like React Native, which claim production-ready and are presumably quite stable in practice, you’re back to version numbers being meaningless, except with the added bonus it’s not even useful for marketing..

It's not meaningless -- the meaning is that there are bugs. That is why the version can indefinitely approach -- but never reach -- 1.

In opposition with SemVer projects, which... ...don't have bugs?

You make a good argument. Anything that keeps the marketers away does seem like a pretty good feature.

I work on Pure Data (https://github.com/pure-data/pure-data/) which has been 0.x for 25 years now :-) The upcoming release will be 0.52.

Well there’s a joke somewhere.

Less has my favorite version numbering system. Sequential.

Latest stable release: Version 598

https://www.greenwoodsoftware.com/less/

My favorite has become just making the version number the release date.

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.

"Tell the user nothing" is your favorite system?

Especially, like, what if you release a bugfix for a significantly old version? Do you give it an up-to-date number? Do you not give it a number at all?

(Also I see a 581.2 on that page.)

Upgrade

> Upgrade

Upgrading is the problem in this scenario. Let's say 727 is the modern version. If users upgrade to 728, when 728 is based on 402, we have an issue.

> we have an issue.

No, we don’t.

It's hard to say much when your replies are so short, but let me try to elaborate.

If a user that was happily using version 727 is now on a version that's almost identical to 402, they're now missing 300 versions' worth of code changes. You don't see how that's an issue? What if they were using functionality from that? Upgrading to 728 has removed all this code they were depending on!

If everyone follows your advice to upgrade, then everyone has this problem. Including you, unless you ignore your own advice.

>If a user that was happily using version 727 is now on a version that's almost identical to 402

lol. That’s not how this works.

> lol. That’s not how this works.

If I give my bugfix to 402 a version number, it will be 728.

So if that's not what happens, what does?

Do I give it no version number?

Am I not allowed to release a bugfix?

Surely you can see why both of those options cause unnecessary problems.

If you have something else in mind, you need to say it.

Never backport fixes. Time only goes forward.

It might not even be a backport. Either way that's a pretty rude system.

And it's not really a version numbering system that you're advocating for at that point, it's a strict rule about linear releases.