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?
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.
And you don’t need to give pet/nick/code names to cryptic version numbers, instead, each release can have it’s own number and pet/nick/code name, without needing to resort to naming long strings of numbers separated by dots, while also having the option to set the rest of the numbers reset to zero, unless you have something against it, in which case it would still work flawlessly.
Release.Breaking.Feature.Fix
By using 4 numbers, we not only get rid of the confusion caused by linking version 456.132.693 to PuddlePlow, BraveYard, SwagMinator, PowderJuice, LiquidMagenta or FlyingRacoon, but we also get rid of having conflicts between releases using different Breaking version numbers even through they’re part of the same release name. What do I mean by that?
- Windows 7 release = v32.69.45
- Windows 8 release = v33.62.71
- Windows 7 Service Pack 1 = v34.12.96 (???)
In exchange, we would have something like this:
- Windows 7 release = v17.12.36.12
- Windows 8 release = v18.3.16.9
- Windows 7 Service Pack 1 = v17.16.2.39
This way, each release would be referring to a different product, instead of a different version of multiple sub-products or product variants being worked on at the same time.
- The first number is for releases which you hope to be adopted by the users, like Microsoft with Windows XP, Windows 7 and Windows 10.
Now you know that if the `release` is incremented, it must be because the developers are suggesting you to update to that version, recommending it and saying that they’re going to stop offering support for the previous `release` soon enough, if they didn’t already stopped. - The second number is for backwards-compatibility-breaking updates, allowing you to know that in order to update from 1.0 to 1.5 you have to go through 1.1, 1.2, 1.3 and 1.4 and not have to search for a list that might look like 1.0.12.683, 1.0.326.2, 1.1.8, 1.3.9, 1.3.9.1, 1.3.9.12, 1.4.0.0.0.3, 1.4.0.3.9, 1.4.2, 1.4.2.6.9, 1.4.9, 1.4.99999 and who knows what other cryptic version numbers.
Now you know that if the `breaking` part is incremented, you some things might break. - The third is for every time a new feature is added without breaking backwards compatibility, like when you allow the users to change their email address , or their public name, or edit a comment.
Now you know that if the `feature` part is incremented, something was be added. - The fourth is for fixing things, like killing bugs, not having the whole thing crash out of the blue and allowing all the users to edit their email, not just one category of users. Also, you can use this to fix things required for a feature update, since you’re fixing some things, but still leave place for more fixing, until a feature update happens.
Now you know that if the `fix` is incremented, there are less errors.
Also, if you don’t yet have a “Release” version that can work on it’s own, that is what the 0 is for: the beginning. So, for example, if you were to start working on Product 32, you would start with v32.0.0.0 being an empty project and build up from there.
By the way, Maxthon already uses (a form of) Explicit Versioning for years already.
And the best thing about it is the fact that it doesen’t require long texts to be comprehended. You can literally explain it by simply writing four words liked with/by dots/points (Release.Breaking.Feature.Fix) and expect most of the developers and a big part of the rest of the users to instantly understand it. And if some did not understand it, an article or two should fix that.
Now compare that with the countless walls of project-dependent text required to understand the Semantic Versioning and you know why most developers (regardless of what they are developing) still don’t fully comprehend it…
I codename this Explicit Versioning #explicitVersioning
And someone made a github page for explicit versioning, using different names for the identifiers, but with the same message in mind.
A proper Release version should be like this:
If you have better ideas or have found flaws in this article, please mention them in the comments section.
If you liked this article, also check out DC’s Hidden Power Ring Corps.
If you liked this article and want to see more like it, don’t forget to like/recommend it, if you want to spread the word maybe share it, and maybe favorite it, if you want to have it at hand, maybe for reading it later.
#explicitVersioning #semver #versioning #semanticversioning #semantics #semanticweb #version #versions #js #php #java #c #c++ #cpp #go #elixirlang #Erlang #Node.js #Developer #Angular #AngularJS #AI #BigData #DataScience #Analytics #MachineLearning
