Join your peers at KMWorld 2018 in Washington DC. Save $200 off your KMWorld Pass with Early Bird pricing.

 

What’s in a name?
Deciphering version vernacular

This article appears in the issue October 2010, [Vol 19, Issue 9]


   Bookmark and Share

Because I keep track of the development of several dozens of products, I have become a somewhat reluctant expert in versioning schemes. When 4.2 follows 4.1, or 6.7 and 7.5 are released simultaneously, all  I really want to know is: How much has changed? You’d expect that  what comes before the dot is a major, and what comes after it is minor. But in reality, there’s often a strange change from major to minor. And when you dig deeper, some minors are quite major.

There are many unwritten rules about version numbering. Anything before 1.0 shouldn’t be used in production. An alpha is for pre-beta testing. RC1 [Release Candidate 1] will be released if it’s without faults, but will become RC2 if it’s not. An increase of the major version number means there are significant changes; in content technologies, you wouldn’t expect to simply upgrade to the new version without major refactoring of your implementation. A minor might be fine, though you should be wary of a sudden jump to .5—that’s usually halfway to a complete overhaul, but doesn’t have the interface buffed up to show for it.

Unfortunately, in reality, numbering schemes are often more about marketing calibration than software development. How else can we get the 2010 version after 2007, without intermediate releases like 2009.11? And while I have a tendency to overuse cars as metaphors for software, that comparison sometimes is pretty close to the truth: The 2011 software models are sure to be upon us in the next few months. When 2.7 turns out to have more impact than 3.0, I’m pretty sure there are other interests at stake than mere version management. That’s not to say I’m a particular fan of the endless decimal fractions that can be generated by daily builds; you can never be quite sure why .1336 breaks your system, while .1337 is fine.

So the main question should be: Why would you care? Vendors will explain what the significance is, and if not, you could always check the release notes. And if it’s a company or project you trust, you might not care. However, I tend to think of version numbers as indicators: They tell you how truthful the advertising is. And when you understand a particular system’s scheme, you’ll know what to expect well ahead of the release date.

Let me put it this way. If I tell you it’s 15 degrees Celsius in The Netherlands right now, that might not mean a lot to you. However, to me, that means I should wear a coat. Because it’s helpful to know the temperature, I’ve learned to understand Fahrenheit as well. That keeps me from catching a cold walking outside without a sweater, or from breaking into a sweat in the heat if I’m wearing too many layers of protection.

Likewise, you might find it worthwhile to spend a little time calibrating to the version numbers of products that are relevant to you. One day you might be saved from a major storm—by sensing that minor change in hot air pressure. 


Search KMWorld

Connect