Versions Madness

Last week, Linus Torvalds, the creator of Linux, published this post on Google+.

So, I made noises some time ago about how I don't want another 2.6.39 where the numbers are big enough that you can't really distinguish them.

We're slowly getting up there again, with 3.20 being imminent, and I'm once more close to running out of fingers and toes.

I was making noises about just moving to 4.0 some time ago. But let's see what people think.

So - continue with v3.20, because bigger numbers are sexy, or just move to v4.0 and reset the numbers to something smaller?

It seems that Linus considers the version number just like a name, unrelated to commercial consideration and even to product features. But often, the choice of the version number is considered a science.

I Like It Complicated

The major-dot-minor format is quite common and also the meaning of those numbers are quite standard: minor changes when there are small improvements while major increases on bigger changes. But after those numbers there may be a wide variety of things:

• a build number, automatically increased at every successful compilation,
• a distribution number or letter, changed every time a build is delivered to testers or customers,
• a letter indicating the build type (alpha, beta, final, etc.),
• abbreviations for special releases (pre, RC, QA, ...)

The funny thing is that some of the above cases may be combined together so, for example, you can find 1.7d RC or 2.1.B.174. By the way, for some years I've used a four-number system to identify delivered versions of my software: after major and minor there was a counter to keep track of small functions changes or refactorings while the last number was related to bug fixed.

The Tech Side

Your software may expose API or use functions provided by other programs. In this case, the version number has a fundamental purpose. Is through this string that your application is related to the others.

Understanding how other developers deal with version numbers can help you to know with which releases of third party softwares your program is compatible. And save you from some serious headaches when a customer claims that nothing is working.

The Commercial Point Of View

Aside these technical considerations, there is also the commercial side of version numbers. To a user or a customer, a change in the major number means that big changes and big improvements have been made. This generates greed for the new version in some people that can be used by salesmen to raise prices. The real important thing in this situation is to meet the expectations of the customer.

Even if the software is free, there is a rise of expectations whenever the change involves the leftmost numbers. And also in this case you cannot disappoint the users. However, for the Linux kernel, the situation is quite different: it's not directly used by final users but only by other developers and system administrators. In this case, Linus' idea is not so bad, in my opinion.

Conclusions

The real important thing is to use a system for indicating the version of your software. It has to be meaningful to you and to your organization and it must be clear enough for the final users. If you want my opinion, Semantic Versioning is pretty good.