Communications - October 2010

able, with three-number versioning— Major.Minor.BugFix—where the major version changes for large features, the minor version changes for small features, and the last number is a bug-fix release. The bug-fix number is perhaps the easiest to understand. After a number of bugs are fixed, you want to release new software into the field so that users can benefit from the work your team has done. Increase the last number and release a new version. Bug fixes should never change an API in a library or introduce or significantly change a feature.

The difference between a major and a minor version change can be tricky depending on the software you are writing. Minor versions can be rolled out so long as there are no backward-incompatible changes to the system. What this means is that if you have a change to your software that will break another piece of software that depends on your code, or that breaks a user assumption about how your system works, that requires a major version change. Additive changes, such as new APIs, or new features that do not break backward compatibility can be rolled into minor version updates.

The slippery slope is figuring out how many minor changes add up to a major change. If your software has 30 features and you add 10 new ones, even if none of them touches the original 30, shouldn’t that necessitate a major version change? I think it should, but not everyone agrees. Of course those who don’t agree—well, let’s just leave that alone, shall we?

One thing that software versions communicate is the rate of change in your software. If your software goes from 1.0 to 2.0 in a month, then either your team is performing miracles, which I find highly suspect, or they’re claiming major changes when none has really occurred. A very high rate of minor or bug releases can also indicate problems in a project—in particular, that it is buggy. Although there is no perfect rate for releases, they should definitely slow down a bit as a product matures. Too-frequent releases often mean that a piece of software is immature and perhaps lacks staying power.

Another pattern, in some projects, is never to release a 1.0, but to release a lot of 0.x’s. A particularly egregious version of this, pun intended, was the

the difference
between a major
and a minor version
change can be tricky
depending on
the software you
are writing.

Ethereal project, which, after more than 10 years of development, got to the point of releasing a 0.99.5. This was just a way, as far as I could tell, of moving the version number to the right. The software itself is quite good and widely used, but its versioning system was quite odd. Now that the project has been renamed Wireshark, it seems to have moved to a more traditional Ma-jor.Minor style of versioning.

Version numbers should also be able to correlate related pieces of software. One of the banes of my existence is the Linux versioning system, although I believe this has more to do with the way Linux itself is developed. The fact that there are now many different operating-system kernels that I might have to choose from to use a piece of related software is simply maddening. A recent example involves having to find the correct bits so I could use a driver for a new piece of hardware. The standard release was 2. 6.18-194.3.1.el5, but the version I needed was, 2. 6.18-164.el. And just what do those numbers mean? Of course I could work them out with some Web searches, but still, the fact that kernel APIs have changed enough within those minor releases that a driver couldn’t work is madness. Even looking at kernel.org, the source of all things Linux kernel, isn’t much help. At the time this column was written these are the kernels that are listed as stable for the 2. 6 version of the kernel:

2. 6. 34

2. 6. 33. 5

2. 6. 32. 15

2. 6. 31. 13

2. 6. 27. 47

2010-05-16

2010-05-26

2010-06-01

2010-04-01

2010-05-26

Now, I ask you, how does 2. 6. 34 come out 10 days before 2. 6. 33. 5, and how can all of these be stable? How do they even relate to each other?

Of course, it’s not just open-source projects that have problems with versioning. The biggest software company of them all seems to have one of the most ridiculous versioning schemes of all. Based on the names alone, how does one figure the difference between Windows 95, Windows 98, Windows ME, Windows NT, Windows XP, Windows XP Service Pack 2, and Vista? I can list them in order only because I have watched them all come and go, and, happily, never installed any of them on my own machines. Perhaps if you hash the names just right, then they turn into monotonically increasing version numbers.

One last thing to note is that you should not tie yourself down with your versioning scheme; remember that you may have to be flexible. I once worked on a product with a 1.0.1b release. The b release was necessitated by a not-so-amusing mistake, wherein a developer decided that if a user saved a file without an extension, the developer would provide one. The extension was a four-letter word that is included in George Carlin’s list of seven things you can never say on TV, and which one should never really have as a file extension either. I think you get the idea. The developer had meant to remove that particular feature before the code was released but forgot, and so, we had 1.0.1 and 1.0.1b releases. We could have made a 1.0.2 release, but, really, there was just one change—though I do believe we should have made the release 1.0.1f.

KV