Every program or app has some kind of version number. With Mac OS X, the X is a Roman numeral for version 10. OS X Lion relates to version 10.7 and the latest release, at the time of writing, is 10.7.1.
OK so what exactly do all these numbers mean and what is the best way to use these numbers when creating your own applications?
I am kicking off a new ‘Programming’ category today. As this is a big part of what I do for a living I thought I should use this opportunity to impart some my knowledge and/or views. To start here is an explanation of how I view version numbers and my recommendation of how to decide which numbers to use.
I was going to mention that Microsoft has gone back to basics with Windows 7 which is version 7 of their Windows operating system but when I dug a little deeper it appears that Windows 7 is actually version 6.1, just a minor change from Windows Vista which was version 6.0…
So will Windows 8 be version 6.2 or 7.0? Only Microsoft could make things so unnecessarily complicated…
Anyway this just goes to show that version numbers are not fixed in any way and so it is entirely up to the developer to decide how best to use them.
From personal experience time can be wasted on some trivial things. Version numbering can become one of these time holes unless you have some rules laid down. To keep myself from wasting any more time I thought I would write down the rules I tend to follow so I have something to refer back to. Hopefully this may be of some use to any other developers out there.
What Makes Up A Version Number?
So as you can see from above a typical version number is generally made up of 3 different numbers, or 4 if you include the build number that is sometimes tagged on the end. There are many different ways of setting up and maintaining version numbers but this collection of numbers seems to be the most obvious and most used so I tend to use this as the basis for any version numbers I create.
At least one of the major, minor or revision numbers must be changed for each release, even if it only for testing purposes, to ensure uniqueness. The build number, if used, must also be unique so you can be sure exactly which release of the application is being used.
So what do each of these numbers refer to and how do you know which one to change when creating a new release?
The first number in the collection is the major version number, 10 for mac in the above example.
This number should only be changed when a major change to the functionality, or development environment, of the application takes place.
When this number is incremented the minor number, and also the revision number, should get set back to 0.
The second number is usually referred to as the minor version number. This number relates to the major version number so to make sense they must be shown together. In the OS X example the 10.7 is the minor version number and has been given a nickname of Lion. The minor number 7 on it’s own has no relevance as you cannot tell it you are talking about version 10.7, 9.7 or 8.7.
This number should be incremented whenever smaller changes to the functionality occur.
When this number is incremented the revision number should get set back to 0.
The third number is sometimes known as the revision number or release number but probably has lots of other names. This number also relates to both the minor and major version numbers so to make it clear you show all of the numbers together when talking about the revision number. When OS X Lion was first released the full version number was 10.7.0. After a few fixes and changes Apple released an update and so the release number was incremented giving a new version of 10.7.1.
This number should be incremented whenever one or more bug fixes or minor changes are added.
If a bug fix changes the functionality then it should really be an increment to the minor number, but this is up to the developer to decide. If, for example, you are adding lots of changes ready for a release then you may want to just increment the minor number once and all subsequent changes, even if they do effect functionality, increment the revision number.
The last number is not actually part of the version number. The build number is simply a way of confirming that the version number is exactly the same as the one you are looking at. In theory whenever you build a new release this number should be incremented to make sure the executable is unique.
This is simple if you have a dedicated build machine. The build number can then simply be auto-incremented on every build, ensuring uniqueness. Every release outside of the development environment must then come from this build machine and never directly from a developer otherwise this uniqueness can be lost.
For single developers then this is also a valid option as you know from the outset that you are always going to release from the same machine so uniqueness can be assured.
Unfortunately for most small teams this may not be the case. One way to get around this would be to stop the auto-incrementing build number. Then when a release is to be created, for outside of the development environment, whether it be for internal testing or an external release, then the build number should be incremented. To make sure this build number is not replicated the build number should then be incremented again after the release is made before being checked into source control.
This way you can insist that all odd number build numbers are internal builds created by developers for personal testing. Then the even number builds will be unique and can be used to release.
Working Towards A New Major Version
This is something I have recently had to think about as the old method I was using didn’t seem to make sense to me. If you have a product that is currently on a minor version of 3.4.5 then next major version you want to release would be 4. So the first release of this updated product should probably be 4.0.0.
Now the problem I had is that the current 3.4.5 version may still be under active development. There may be a 3.4.6 release planned to fix a few bugs and a 3.5.0 version with some minor changes on the horizon.
This shouldn’t be a problem you can just change the version number to 4.0.0 for your new major update, right. Well, the problem comes when you go to release a version for internal testing. If the testing means that you are required to release a few bugfix releases and possible have to change the functionality when an issue is brought to light so the version number may already be something like 4.1.2 before you are ready to create the first real version 4 release…
So this isn’t ideal but how can you make it clear that your version is working towards a 4.0 release?
I have seen some programs that add a character at the end of the version number to specify that it is an alpha or beta, e.g. 4.0.0b1 would specify that this version is the first beta release. (Just for completeness alpha relates to an early stage release and beta refers to a version that is nearing a final release)
I personally do not like this as I tend to think of the version as being a collection of numbers rather than just a string of characters. There are advantages to this system though as you can instantly see from the version number the expected state of the release, i.e. alpha or beta.
Anyway now to my idea/method. Create a new minor version, high enough not to clash with any future versions of the current major version. In the above example this could be 3.99 or 3.999 depending on the likelihood of continued development on the current 3.5 version. Then you can carry on incrementing minor and release numbers as required until you have a version ready to be released as 4.0.0.