Linux.com

The problem is not that several different versioning systems exist. Once you realize there are variations, you should have no trouble picking up on the fact that the odd-numbered GNOME releases are development builds and even-numbered ones are official releases. Nor are you likely to mistake KOffice 1.9.95-4 for a late version of KOffice 1.0 for more than a moment before you realize that it is an early version 2.0 build. Anyone familiar enough with free software to be trying the latest builds knows that getting all of a large project's developers to agree on anything besides their mistrust of Microsoft is impossible. We learn to allow for idiosyncrasies.

Rather, the problem is that, no matter what the system, a version number often says nothing about how far along the software happens to be in the development process. Some projects, such as OpenOffice.org, have abandoned versioning except for the final release, and simply label each release as a build. But for every project like Firefox that forthrightly uses names such as "firefox3.0-rc1," dozens are using both the traditional three-digit version number and terms like "beta," "alpha," and "release candidate" so loosely that they no longer carry any meaning.

The way it should be -- and isn't

Version numbering, of course, is partly a matter of judgment -- a reality that Linus Torvalds frequently emphasizes when he announces a new kernel. For instance, five years ago, he announced the long-awaited 2.6.0 with, "This should not be a big surprise to anybody on the list any more, since we've been building up to it for a long time now.... Anyway, 2.6.0 is out there now." The implication that version numbering is arbitrary, and perhaps more a marketer's concern than a developer's one, could hardly be clearer.

Still, over the years, a broad consensus about what to expect in a release cycle has emerged. First come the development releases or nightly builds. Then, at some point around version 0.2 or 0.3, one release is declared -- somewhat arbitrarily -- the alpha release, which, in free software, designates a release in which major functionality is more or less enabled. Somewhere between versions 0.6 and 0.8, a beta is declared, meaning a version in which all the features of the major release are present, and the interface is almost finalized, but in which bugs are still being worked out. When all the showstoppers are fixed, one or more release candidates are released, and finally, a few minor fixes later, the major 1.0 release. The major release may not be bug-free, largely because of the problems of testing on enough different combinations of hardware, but it is supposed to be functional for most users.

That's what users have come to expect. The modern reality is somewhat different. Increasingly, I've seen releases with versions edging towards a whole number in which major functionality was still being implemented. When I reviewed BashStyle-NG, a desktop utility for customizing the shell, much of the interface was still in flux, even though I was using the third release candidate. In a more extreme case, KDE announced 4.0, and its development team then expressed surprise when people tried to use it in their daily work. Version 4.1 was what users wanted, they hurried to explain as the complaints rolled in.

Similarly, when the Foresight distribution has an alpha four release, then obviously the term "alpha" no longer carries meaning, even when you make allowances for the problems of a large project that consists of largely distinct modules. If a fourth alpha exists, then surely the first one was misnamed.

In a similar situation, Cyrille Berger, a KOffice developer, explains the fact that version 2.0 is now in its eighth alpha as due the size and complexity of the project. Designating so many releases as "alpha," he says, "is the only way to show that the project is still alive and is making progress." Berger acknowledges that "after the 2.0 release, we will follow a much shorter release cycle, with much fewer alphas," but meanwhile, the price is user confusion.

Consequences and solutions

When this out-of-control versioning errs in the opposite direction, it causes few problems. When FontMatrix's 0.1 release proved a fully functional font manager, I was pleasantly surprised. Not only was it software still in development that I could use without enduring any crashes or workarounds, but I couldn't help thinking that, if an early release was so polished, what heights would the official release reach?

But users who download and compile a release whose number or status is inflated are only going to have their expectations deflated. Instead of getting involved in the project and filing bug reports to help nurse development along, they are more apt to turn away in disgust, and it may be years before they return. And each time that happens, the project with inflated versions loses a chance to build its community.

Part of the problem, perhaps, is that version numbers are a legacy or an imposition from commercial development. Some might say they make no sense in free software, with its philosophy of "release early, release often." However, free software is increasingly commercial these days. If projects can compromise enough with business to have regular release schedules, then accurate versioning hardly seems too much to ask.

Or, if accurate versioning is impractical, one answer might be to adopt the loose categories suggested by Debian's cascading repositories: unstable, testing, and stable. That would be enough to tell users what to expect. Then official releases could be named more or less by fiat, the way that Debian has all along.

Whatever solution they choose, free software projects need to be more careful about versioning. Doing so would be doing everyone a favor.

Share    Print    Comments