Some esoteric versioning schemes (monotonic moronity)

Since time immemorial, software has had version numbers. A developer releases V1 of their product. Some time later, they add new features or fix bugs, and release the next version.

What should that next version be called? Modern software broadly bifurcates into two competing standards; SemVer and CalVer.

SemVer

Semantic Versioning is usually in the form 1.2.3, the last digit is usually for minor bug fixes, the second digit for new functionality, and the primary digit for big and/or breaking changes.

The semantics are pretty loose. There's no real consensus on when a new "primary" number should be issued. There are two main weaknesses:

1. The numbers might not be decimals. Is V1.29 newer or older than V1.3?
2. There's no semantic information about when the software was released.

Which leads us to…

CalVer

Calendar Versioning is, ironically, more semantic than SemVer. The version number is the date when the software was released. For example, Ubuntu releases are in the form of YY.MM - the latest stable release at the time of writing is 24.04 - so we can tell that it was released in April 2024.

There are three main problems with this approach.

1. ISO8601 or GTFO! Surely these should use YYYY-MM to make it obvious this is a date?
2. Minor bug fixes are often given a release number like 24.04.1 - is that still obvious it is date-based? Was it really released on the 1st of April?
3. No information about big and/or breaking changes. Software released several years apart may be functionally identical whereas software released days apart may be incompatible.

Alternatives

So, what other ways can we number software versions?

EffVer

Effort Versioning is, I think, a sensible way to standardise SemVer. It attempts to show how much effort it takes to move between versions.

PrideVer

How much Pride do you have in your software release?

This is SemVer for people with an ego and the coding chops to match.

RuffVer

Ruff is a sort of bastard child between SemVer and CalVer, but adds this delightful complication:

Stable releases use even numbers in minor version component: 2024.30.0, 2024.32.0, 2024.34.0, … Preview releases use odd numbers in minor version component: 2024.31.0, 2024.33.0, 2024.35.0, …

It's the versioning equivalent of setting up a fully scalable cloud database and hand-chiselling HTML out of stone for the cookery blog you update twice per year.

0Ver

Zero-based Versioning tells us that it is forbidden to ask and a sin to know when a piece of software will be completed.

Essentially, it is SemVer for cowards who are afraid to commit. The opposite of PriveVer.

PiVer

The venerable TeX uses Pi Versioning. The current version is 3.141592653, the next version will be 3.1415926535.

As the software gets refined, it gradually reaches a state of perfection. This is a charming versioning scheme which shouldn't be used by anyone other than Knuth lest hubris overtake you!

NameVer

Sometimes marketing takes the reins and insists that consumers need a Named Version to help prevent confusion.

Ubuntu uses things like Bionic Beaver, Distinct Dropbear, and Mantic Minotaur. By convention, names increase alphabetically, so you should know that Jaundiced Jackdaw is before Killer Kangaroo - until you've released 26 version and have to wrap around the alphabet again.

NameVer is helpful for distinct products which aren't related, but probably more confusing than necessary.

WinVer

Microsoft Windows uses this very logical scheme - 1, 2, 3, 3.11, 98, 2000, Me, XP, Vista, 7, 8, 10, 11.

It starts with more-or-less SemVer, then jumps to CalVer, then 4 digit CalVer, then to NameVer, then back to SemVer - skipping 9 because of alleged technical reasons.

Do not attempt to use this versioning unless you want to anger both gods and mortals.

KelVer

Absolute Zero is defined as 0K. And so, Kelvin Versioning counts down to stability.

Almost the opposite of PiVer - the closer this gets to zero, the closer the code is to being complete.

This versioning scheme is affront to most sane people. But here's to the crazy ones.

Non-Monotonic

You will notice that all of the above are monotonic. That is, they all proceed in one direction and never reverse. Any subsequent version was definitely released later than a previous version. So, in a sense, they all contain some level of semantics.

But they don't have to.

HashVer

Taking the Cryptographic Hash of the code, or a commit, allows one to create Hash Versioning. For example 43317b7 is a HashVer for something which would otherwise have the dull and unworthy name of v0.118.1

But, of course, a hash does have a modicum of semantic information - even if it is only loosely related to the content of the code. What if there were something with no semantics and no monotonic behaviour!?!?

RandVer

Embrace the weird with Random Versioning! It its heart, RandVer says pick any number that hasn't been used before.

Perhaps V7 is followed by V2.5, which is overtaken by V0xDEADBEEF

Absolutely guaranteed to have zero semantic content.

What have we learned today?

The square-root of bugger-all.