A plea for sanity in software versioning

Holy cow, when did it get so hard to make sense of software version numbers?

If you use Google’s Chrome Web browser, you’re probably using version 12 right now. If you’ve configured it for the bleeding-edge developer channel, you might be on version 14. By comparison, the Oracle database is on version 11, and it’s been around since the 1970s. Chrome must be a pretty mature product, right?

Not really. The first, early-preview release of Chrome shipped in September 2008. That makes 12 major-version releases in less than three years.

[ The InfoWorld Test Center reviews the new crop of mobile browsers. | Get software development news and insights from InfoWorld’s Developer World newsletter. | And sharpen your HTML5 knowledge with the “HTML5 How-to Deep Dive” PDF special report. ]

This is, of course, absolutely ludicrous. Everybody knows what a major-version release means. Some joker even coined the adjective “2.0,” as in “Web 2.0” or “scrambled eggs 2.0,” meaning a brand-new version of something that’s so different from the old version that you’re going to have to learn how to do it all over again. Chrome’s so-called major versions hardly count.

But it’s easy to guess why a company would do this. Consumers always want the latest and greatest. Give them a new version number and they’ll all rush to get the new features. Software that stays at the same version for too long looks old and outdated.

Chrome has been so successful with its numbering scheme, in fact, that its competition decided to get in on the act. In March, the Mozilla Foundation announced that it would begin releasing a new version of Firefox every 16 weeks, instead of once a year as it had been doing.

So far it’s been better than its word. Firefox 4 came out on March 22, 2011. Firefox 5 shipped June 11 — just 13 weeks later. Meanwhile, in the opposing camp, Chrome 6 and 7 weren’t even two months apart.

Can customers even keep up with release cycles that fast? It all sounds like nonsense.

An embarrassment of Firefox versions Firefox’s version numbering is particularly frustrating because the Mozilla Foundation seems to have abandoned all rhyme and reason. By most accounts, Firefox 5 is little more than Firefox 4 with fog lamps and a cupholder. But the Mozilla developers haven’t been lazy; a memory sandbox feature that runs plug-ins in a separate process, so that when plug-ins crash they don’t take down your whole browser session, was added in Firefox 3.6.4. Who says minor-version releases don’t count?

Firefox’s new, rapid version-numbering scheme has caused problems for users who rely on plug-ins, too. Firefox plug-ins must specify which versions of the browser they work with. When the browser version changes too quickly for plug-in authors to keep up, their plug-ins can stop working automatically, even when nothing about the new version of the browser makes it technically incompatible.

According to Web metrics firm StatCounter, nearly a third of all Firefox users are still on version 3.6.x, mostly due to plug-in issues. Firefox 3.6’s user share is still twice that of Firefox 4.

All of this has been maddening for enterprise IT directors, who often have to run extensive test cycles on internal Web apps before deploying any new version of the browser. In this case, Mozilla not only issued a new version but withdrew security support for Firefox 4 — which means no new patches — barely three months after it was released, in a move IBM’s John Walicki described as “a kick in the stomach.”

Are these numbers necessary? There are better ways to handle version numbering. One is not to use version numbers in your software marketing at all. For example, Microsoft went from Windows 2000 to Windows XP to Windows Vista, then released Windows 7 and Windows Server 2008 at the same time.

Each release of Windows also has an internal version number, which only Microsoft developers really care about. For example, both Windows Vista and Windows 7 are major version 6.x, which makes sense, given the technical similarities between the two products. Customers rarely know which actual version of Windows they’re running, however, and they rarely need to.

Ubuntu Linux has maybe the smartest versioning scheme I know of. Ubuntu releases are numbered based on the current year and the month in which the product shipped. The most recent release came out in April, so that was version 11.04. Version 11.10 will ship in October.

That’s clever, because it fulfills two purposes of a version-numbering scheme: It lets customers know that a newer version is out, and it reveals distinguishing information about each new release. The number doesn’t necessarily tell you what’s technically different about the new version, but because every Ubuntu release gets 18 months of support from Canonical, customers know that support for Ubuntu 11.04 will expire in October 2012, just by looking at the version number.

How not to release software Which brings us back to Chrome: Google’s numbering is strange because it doesn’t seem to fulfill either purpose. New major versions don’t seem to coincide with major technical changes, and users often can’t tell the difference between one version and the next. What’s more, Chrome version numbers don’t really get users excited about new versions, because Chrome updates itself to the latest version automatically. Most Chrome users couldn’t tell you which version they were using without checking.

One possible answer is that Google’s version numbers aren’t meant to rile up Chrome customers, but to rile up Chrome competitors. One of the stated goals of the Chrome project is to advance browser technology. By releasing new versions of Chrome rapidly, Google puts pressure on competing browser vendors to do the same. It seems Mozilla, at least, has taken the bait.

That’s dumb. However much consumers may want “new and improved,” shipping code before it’s ready is never a smart business plan, particularly when your new “major update” doesn’t seem to deliver any appreciable changes. In fact, for a software developer, pressuring your competitors to abandon sane, reliable release schedules — thus confusing their market and lowering customers’ expectations of their product — might be a pretty shrewd business tactic. Why hasn’t anyone thought of it?

This article, “A plea for sanity in software versioning,” originally appeared at InfoWorld.com. Read more of Neil McAllister’s Fatal Exception blog and follow the latest news in programming at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.