This article just reached Version 2.1.2.0

The Software Versions are broken. But don’t worry, there is a fix for that: The Explicit Versioning. And you need to know that, whether you’re a Coder, Programmer, Engineer, Designer or a Developer of any type of product! As stated in that article, the current versioning system is flawed, allowing for a lot of problems, with their numbers and importance increasing as the version number increases. And thanks to that, the flawed system has already started to be replaced.

But why would you switch to another system, or start using one? After all, you don’t want to lose any more precious time on meta-development. Well, that’s the point, you’re spending a few minutes now so you don’t have to spend hours or even days later. And the new system is much easier to understand and follow than the previous one, while still providing the benefits the previous one provided. Still not convinced? Here are some reasons why you should at least try it:

You don’t need a lot of text for the users (other developers, for example, or you a few months down the line) to understand it, since you can sum it up into four words separated by dots: Release.Breaking.Feature.Fix

And since the previous system allowed and in some cases even encouraged the use of four numbers, there should not be any issues with the compatibility with the systems you’re currently using.

This way, not only you but also your users will know what they should be expecting when deciding weither to update or not. After all, if you launch daily updates, if they have nothing critical to worry about, why would they spend time (and money) updating to a newer version, so long as you are still offering support for the version they have?

Example of bad versioning trying to be good

Expressiveness

What is Major release supposed to be? What about a Minor release? And what about a Build release? Oh, and let’s not forget about the commonly met Revision release. Well, revision is supposed to be something that doesen’t makes a build, but is still progress, and a build is supposed to be a working/functioning/proper version.

So that leaves us with 2 version numbers that could literally mean anything: Major and Minor. And you need to read the project’s documentation to understand that, since they might mean different things depending on the project.

Release nicknames

If it’s time to write a blog post to inform the community about new features or important changes, find the version you want to publicize, tag it “latest”, and give it a human-readable name (e.g., “MVP”, “Aardvark”, etc…). That human readable release name does not replace SemVer. “MVP” might correspond to v1.6.23 or v2.2.5 — the point is, the numbered version has nothing to do with the named release.

Needing to use release nicknames so the clients know what version they are talking about, while you, as a developer, only have access to version numbers, might be detrimental in the long run. Why? Because it creates possible bottlenecks and require the developers to know what name refers to what version or branch, or take/spend time to try to find that out.

Also, needing to link a nickname to a version number of a product with an already existing name is… let’s just say too much to worry about (like the copyright concerns, for example). And how would Windows 7 BottleNeck should as an alternative name for Windows 7 Service Pack 1?

Even if you call it Windows 7 Lullaby or Windows 7 Marshmallow, it still would not be good, because (1) you’re forcing onto the client a nickname for a sub-version of the product and (2) you could (and probably would) create confusion (is this Marshmallow a Windows or an Android?).

Sure, Android 4 having one nickname and Android 5 having another nickname is good, but Android 5.0 having one nickname and Android 5.1 having another nickname is not so good. Why? Because each major version requiring support in and on itself now gets a nickname encouraging the users to update to it, and the sub-versions get reseted to 0.