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.