Application Version Numbering

September 16, 2011 By Pete O'Shea

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.

Side Note

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.

Major.Minor.Revision (Build)

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?

Major Number

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.

Minor Number

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.

Revision Number

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.

Build 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.

[SignOff]

Rugby World Cup 2011

Using Google Calendars Offline On Computer, iPhone Or iPad

3 comments

Shirl

September 09, 2011 at 11:49 AM

Sounds very technicalx

Michael Ludgate

September 09, 2011 at 7:15 PM

Multiple development branches aren’t a problem for testing. Version numbers are great for matching up programs with required software, configuration and documentation, but that’s where it stops. Whenever a new build is given to testing, it’s just that a new build. The tester should use the build number, as it’s sole function is to track a programs compilation (implies changes requiring testing) history .

Alpha and Beta are designations, they shouldn’t be used instead of proper version & build numbering. Alpha is an application that is in active development (read as: design & development, not debugging & development) and is not made generally available, usually this is includes activities such as a mock-up for customer implementation acceptance, it’s unlikely to do anything useful or even have much beside the veneer of RAD.

Beta is the point where an application has the majority of core features, a central engine is in place, but probably isn’t hooked up fully. At this point you can release to a carefully selected audience, they’ve signed disclaimers that say they wont talk about your program. Why? 1.Because the cuts are still spewing out and people can see how things work 2.They see when they don’t and you’d rather avoid pre-release negative advertising.

Both of these states should only be inferred on a project, not it’s sub releases. Saying you’re putting out the next sub/version as beta is saying “Here’s something that isn’t good enough, we’d like you to test (and pay for). Let us know how bad it is and don’t get upset, cos hey – it’s beta”. Any well thought-out process is only as good as adhered. Version numbering has enemies, programmers following poor development & release cycles “Oh no! the numbers are getting too high too quickly and people will think (read as: know) we keeping trying to put out stuff that doesn’t work”, and marketing who don’t care that we’re on version n because they want a higher number than a rival.

Pete O'Shea

October 10, 2011 at 8:37 AM

Hi Michael,

There’s a lot of points in your comment so I’ll try and tackle them all one at a a time.

Unfortunately the build number alone should not be considered unique. This may, accidentally, be the case if the development is always done on a single branch in source control and always built on the same machine but this just isn’t practical in pretty much any development team environment. Take the multiple branches for example. To keep the build number unique you would have to go through every branch and update the build number every time a new build is produced. Even then you cannot force every developer to pick up the new build number immediately…

There is no set method for version numbering. My method above is just one of many. Some development teams use the alpha and beta as part of the version number which is perfectly legitimate. As an example of this Lightning (the calendar add-on for Thunderbird) is currently as version 1.0b7 as it is still considered beta.

Releasing new versions as beta is perfectly acceptable as well. In fact in a lot of cases this is pretty much required as any reasonably sized change requires a lot of testing. Most big projects release their software to the public as an optional beta to let people get their hands on it early to help find any bugs or problems before it is ready for a full release. The project is not in beta, as such, as there is still a stable version out in the wild for general consumption, it is just the latest version that is in beta. With big major version changes there is quite often an alpha version available for hardcore users to try out early on in the development cycle to be able to give their opinions and help push for changes they require before you even get into the beta stages.

As for comparing version numbers to competitors then that is purely a marketing thing and shouldn’t really bother the developers. As long as the version numbers (inclusive of the build number) remain unique for each release then the rest is pretty much irrelevant…

Anyway I hope I covered all of your points.

Cheers,
Pete