Version numbers, what are they good for? [LWN.net]

Somewhere in last year's LWN mail there were a couple of letters wanting to know more about the version numbers in Linux distributions. Do they mean anything? What do they tell you about a product? This subject has also prompted a lively debate on the Debian-devel mailing list (beginning with this post).

The bottom line is, version numbers are arbitrary constructs and meaningless when comparing different distributions. Within a distribution the numbers do say more. For example, Red Hat Linux 8.0 is a major new release with lots of new features, while Red Hat Linux 8.1 will add mostly security and bug fixes. The same is true for other major new releases such SCO Linux 4.0 (powered by UnitedLinux 1.0) and Mandrake Linux 9.0.

The difference between a major and minor release can also be subjective. Is it the number of new packages that have been added? Maybe its just one or two new packages that add significant features. Are the upgraded packages bug fix releases of the previous version, or do they add new features. Is there a new Linux kernel packaged with the new version, and does it add new features or provide patches? While most new features are held until the next x.0 release, some may creep into a distribution by the x.3 release. It's all up to the distribution provider.

The major.minor scheme is not the only one. A version 3.0 might next become 3.0.1, if the developer feels it is somehow less than a 3.1 release. Names and dates are also used in distribution versioning. Debian GNU/Linux 3.0 is known as woody. Woody was preceeded by potato (2.2) and is succeeded by sarge. Sarge doesn't have a number yet, just the name. Red Hat names beta releases. The beta known as Psyche became 8.0. Phoebe is available now as an unnumbered beta, which when ready will become 8.1. In other schemes Phoebe could be called 8.1 beta or maybe 8.1rc1. Somehow calling a version a "release candidate" makes it sound more stable than a "beta", but that doesn't make it so. Adding a date to the version number is an easy way of telling whether or not the release is current. DistroX 20030108 would be more current than DistroX 20021103, but the major/minor aspect is lost.

Even where a distribution begins numbering is quite arbitrary. Some are released at version 1.0, others start at 0.5 or perhaps 0.0.1, or maybe 5.1 because they are based on someone else's 5.1 release. No wonder then that a 4.0 release from one distribution is as current as a 9.0 release from a another distribution. There is no standard, and there is not likely to be one any time soon. Names are fun, but pretty meaningless. Dates are great, especially when combined with a major.minor number such as KNOPPIX (currently at v3.1-2003-01-01). Whatever the scheme, we can only hope that each distribution provider picks one scheme and sticks to it, so that DistroX 20021103 doesn't become DistroX 3.2 next.

(Log in to post comments)

Version numbers, what are they good for?

Posted Jan 9, 2003 14:54 UTC (Thu) by brugolsky (✭ supporter ✭, #28) [Link]

Recent Red Hat major release numbers imply binary compatibility between minor releases. This is basically a gcc (esp. C++) and glibc ABI issue. It means, for example, that one ought to be able to build an appplication package on RH7.3, and run it on RH7.2, given that the appropriate package dependencies are satisified. Now that gcc-3.2.1 is thought to have a (nearly) stable C++ ABI and the thread-local storage extensions have solidified (on x86(-64) and Itanium at least), along with the glibc versioning mechanism, it will be interesting to see how long the 8.x series lasts.

Version numbers, what are they good for?

Posted Jan 10, 2003 12:30 UTC (Fri) by stijn (subscriber, #570) [Link]

For my own pet projects, I use the date. But I find the 20021103 and 2003-01-01 type tags horrid as they are difficult to read, overly long, and generally annoying as part of a file name, so I use 03-010 instead, meaning day 10 in year 03. Somewhere in December this year will give 03-352 for example. It's great to know the exact number of days between two releases so easily :) Additionally, I keep a version number. It's now at 1.002, and I intend to cycle all the way through 1.003 up to 1.999, 2.000, 2.001, and beyond. But I'll probably get stuck somewhere below 2.000.

Version numbers, what are they good for?

Posted Jan 16, 2003 18:28 UTC (Thu) by OpalMirror (guest, #9132) [Link]

I worked on one proprietary software project which was such an immense software project, that the initial offering was released to customers in phases, using "Customer Availability" version numbers: CA1 (1.0) and CA2 (2.0) were not up to use for any customer, so the first version customers saw was 3.0, which was painfully slow and clunky, with very limited functionality. The team of 40-50 developers went back to work and developed 4.0 (added a programmatic command language) and finally, the first mostly functional but still poorly performing version was 5.0.

Marketing did some looking around and realized that an initial product release of version 5.0 really made some customers uneasy, so for our first real update (the first really quality version of the product, with acceptable performance), we called it "Release 2 Version 1.0". Heh. It worked, even if internally was called it 6.0 or CA6...