There are many, many ways for naming versions of your software but only a few that really make sense to me. And I’m not saying this in an absolute term but with a specific idea in mind.
As a developer you will (or at least should) track your code with version control software like Git, Mercurial, SVN, etc. These applications have their own way to generate version numbers which are usually far from being intuitive, like generating random hashes.
If you would write your own software that only you would ever use this might already be enough. But as soon as there are multiple persons involved, people outside your developer circle, offering a human readable version number is a must.
There are basically three groups of target audiences that require that approach:
- Third-party developers
- Software/Usability testers
- Customers, users, admins
It’s been a trend lately to kinda pervert the versioning system by increasing the numbers so fast that they lose all the abilities to get at least some information other than “this version seems to be newer than the other”. The web browsers Chrome and Firefox are shiny (negative) examples of that! I would highly recommend either getting rid of version numbers completely or using a system that can make sense to almost everyone.
By far, the most common versioning pattern is {full version}.{feature}.{bug(fix)}({stage})
So when you update from version 1.2.0 to 1.5.2 you can immediately see that a few features have been added (or were being removed) and even some bug fixes have already been made. Or if you’re about to install 1.5.3b you should be aware that this software is still in a beta stage and that it might not be working 100% at this point. And so on and so on.
Often developers struggle with how to assign what number for what achievement. And there also seems to be a fear of making full version releases. When you take look at directories like WordPress.org/extend/plugins/ you will see a vast number of software that might even be out there for years that never seems to have reached version 1.0! It’s only my personal opinion but I think that’s just stupid. Maybe some developers think that a software still being a 0.5.22 is a better excuse if something’s wrong (“Dude, it’s not even the final version!”). But if you would take the term “final” literally that’ll be the stage of your software when it’s no longer being developed at all or supported. That’s ‘final’!
When you start a new software project you should do some planning ahead. And one part of that process is to make a list of features or functionalities that you think the first public release should have. Every software has a purpose and this core can be expected to be working when someone is installing your software.
So what I do is to rank the features in terms of importance and other dependencies and assign a number to each of them. So until the software is being released, the {full version} number will be 0 and the {feature} number will increase according to the number of finished features. If each feature of your list has been implemented you can do a major round of testing and documentation etc and if that’s also done, you can (and should) release version 1.0.
From here on, you can either react on feedback (bug reports and feature requests) or implement some new ideas by increasing the {feature} and {bug(fix)} numbers to an open end. And if you make some major changes like to the architecture or you’re implementing some new bigger features you might think (twice) about going for a new {full version} number.
Just as a reminder: Version numbers are not necessarily for you and your team of developers but for all the other people out there. So make them as clear and understandable as possible!
Other Versioning Patterns
So why are there even other patterns if the one mentioned above is meant to be so great? Well, other patterns have other intentions, simple as that.
For example, when using {yy}.{mm}.{dd}.{n} you can instantly see when a release has been made. This might be handy if you know that your environment has changed at some point in time. Or you can see when product has not been updated in ages – which then might be a good indicator that it’s not being supported any longer.
You can also combine these two aspects to a certain extend by adding the release year to your product name or starting the {full version} number with the year but keeping the rest as mentioned above.
And if you can be sure that the version number won’t matter to the average Joe or Jane you can get a bit more technical and include build numbers (which of course also depends on the type of programming you’re using).
So to draw a resume: Think about how you what the versioning should communicate and to whom this might be useful and don’t be clever about it, simplicity’s king here!
3LpC 