Make your version numbers count

Posted in Technicalon Jun 3, 2013

I’ve seen many software products have a version numbers in the form of:

X.Y.Z

Where X, Y, and Z are integers. For example, I’m using Linux 3.8.0.

Communicating a software version number is important because it communicates the fact that the same software title can be different between versions.

Unfortunately, when using X.Y.Z numbering, too many software publishers leaves the meaning out of the components of the version number. Often changes in X mean “big change”, changes in Y mean “medium change” and changes in Z mean “small change”. So software of version 3.2.1 is much better than version 1.2.3, but version 1.0.2 is only minimally better than version 1.0.1.

The problem with this is that it it is subjective. What a publisher considers a big change might not be important to a particular customer. What a publisher considers a small change might fix a show-stopping bug for another customer. When it takes someone’s judgement to decide the version number of the next release, your version numbering scheme is messed up.

When choosing a version numbering scheme it is important to remember how the version number will be used. Sometimes, a customer wants to know how old a software release is, in which case a date-based scheme might be appropariate. In many situations, a customer only wants to know if one version is newer than another version. In this case, I might suggest a simple numbering scheme where version 20 is newer than version 19 is newer than 18.

Firefox uses an X.Y scheme where X is the release number and Y indicates how many bugfix re-releases have been made. For example, Firefox 21.2 would indicate the second bugfix release for the 21st new feature release of Firefox.

When developing a software library, I like to use an X.Y.Z numbering scheme. If the API to the library is backwards incompatible, then X increments (and Y and Z reset to zero). If I add a new feature, then I increment Y (and Z is reset to zero), and I increment Z if I fix a bug. Consumers of my library can look at the version numbering to help them quickly decide whether or not they should update. If they see only Z change, then they should be able to get the only the bug fixes and improve stability. If they need to use a new feature, they should use a version with an incremented Y component. If the X component of the version changes, the library should not be updated until the developer has an opportunity to review the changes and adapt the consumer of the library.

Comment Form

Categories