Over the last few months, I have been co-handling the release procedure for our builds. This task primarily stemmed from the fact, that I was involved with the design of the *build* infrastructure for our product(s). I realised an interesting thing about versioning a software, which is said to be closely tied with "Software Engineering" (SE) principles, a publicly despised subject in our graduation curriculum.
(What I mean by versioning a software is, regarding the x.y.z string that you normally see in a software package you use, following the name of the software, e.g. Firefox 2.0.0.4, and how do you decide when to change one of these digits.)
One does not need much of SE knowledge, in order to come up with a versioning scheme. This can be dictated solely by common-sense. In layman terms, what I mean is, that SE principles will tell you what processes to follow when you release a software build, but they do not tell you which of those digits to change, and by how much. An example versioning scheme:
I number all my releases in the x.y.z format. My first release is 1.0.0. Now, all my immediate minor bug fixes, like typos, formatting changes, etc. will go into version 1.0.1. Following minor bug fixes will go into version 1.0.2, and so on. This essentially means that there will be no functionality changes in any of the 1.0.x versions of my software.
A slightly more critical change will go into version 1.1.0. This may include changes like support for a new browser, changes in the GUI layout, etc. Once again, minor bug fixes will keep going into versions 1.1.x. So, the functionality in 1.0.x and 1.1.x still does not vary, but still I can say that my 1.1.x release works better than my 1.0.x release.
Now, when I do a major feature addition (/removal) in my software, I will change my version to 2.0.0. These changes may be on the lines of addition of new capabilities, support for a new OS, a new platform, a rehaul in the design of the software, etc. And the changes in the smaller numbers mentioned above continue for version 2.0.0.
Now, this mechanism of changing these numbers can change based on many factors. The foremost criteria that I came across, is the kind of upgrade procedure that you follow and support (as will be agreed by Sujay), and vice-versa. Continuing with the example:
In this scheme, it is obvious that a customer should be allowed to upgrade to any of the versions where the last digit changes, i.e. from 1.0.3 to 1.0.4 or 1.0.5.
Also, since 1.1.0 does not have any functionality modifications, she should be allowed to upgrade even if the second digit changes, i.e. from 1.0.x to 1.1.x.
However, since versions 2.0.x involve a major change in the way things work, upgrading can prove to be a headache, and may even result in data loss, all the more so if the upgrading mechanism itself undergoes a change.
Now, if your upgrading mechanism does not follow these rules, then your versioning system is reduced to only a series of numbers to distinguish between different builds. And if you want you upgrading system to be able to jump from any release to any higher release, then again your versioning system should be designed to allow that.
Other factors that may come into play when you design a versioning system for your software may be:
- the source code repository being used,
- the number of products which come under the same versioning system,
- the number of configuration options for a single release, etc.
Some of the common versioning mechanisms currently in use are:
- Date - e.g. Wine 20040505 (released on 05/05/2004)
- Year - e.g. Windows 98, Windows 2000, MS Office 2003
- Alphanumeric - e.g. Windows XP, Windows ME
- Even number releases - e.g. kernel 2.4, kernel 2.6 (kernel 2.3, kernel 2.5 are for development)
- Floating point - e.g. Perl 5.8.7 is actually Perl 5.008007
