views:

202

answers:

3

One of my colleagues told me today that some projects use a weird, IMHO, way of versioning their releases. If the release is unstable, the minor version is an odd number, eg. 1.3, 1.5. On the other hand, stable releases have an even minor version number, eg. 1.2, 1.4.

At first I couldn't believe my ears, it seemed unreal. Then Wikipedia enlightened me that it is a practice coming from the Linux kernel community, although it seems(?) to have been dropped recently.

A few hours later, I'm reading Programming Ruby's preface, and what do I see? Ruby uses the same convention for version numbers.

What's your experience with this? What (open-source) projects/products you know of that use this versioning schema? Is there an easy way to figure it out quickly if they observe this convention? Is it that popular? I've begun software development a little more than 3 years ago and haven't heard about this practice before.

Thanks for your responses.

+1  A: 

The linux kernel dropped that practice with the start of the 2.6 kernel in 2003 (i.e. 2.4 was the last stable with a corresponding 2.5 development branch). I just looked up what I wrote in my master thesis about projects generally:

A split between a stable and a development branch is a very common strategy in open source projects, although some use more{footnote}. The release numbers used is then also often using a odd/even scheme on the form a.b.c where a is a major release number, b is even for stable and odd for development and c is a sequence release number (sometimes an additional d is also used).

{footnote} For instance, the XEmacs development is split between three branches: stable, gamma, and beta. Debian uses experimental, unstable, testing and stable.

For more details about the linux kernel, feel free to read the whole "2.2.4 Linux development branches" chapter.

hlovdal
Thanks hlovdal. Nice subject for a master thesis.
Ionuț G. Stan
+2  A: 

Many open source projects did use this, but most have changed to other methods. For example the Linux kernel used to do this (quite a while ago). Recently, Mesa (the open source OpenGL stack for Linux) stopped using this method with version 2.5.

IMHO, all releases should be relatively stable. If it is not yet stable it should be an alpha or beta release. For example, the KDE 4.0 release was a terrible mistake. 4.0 should have been alpha. 4.1 should have been beta. 4.2 was the first really usable release.

Zifre
Well, I would say that for projects which do use that versioning scheme, releasing a version with an odd minor number serves the same purpose as labelling the release as beta. KDE 4.0 however is a different matter as there was nothing in the version number marking it as unstable.
sepp2k
@sepp2k: while that versioning scheme does serve the same purpose as beta, you can't expect users to know that. Many users like to have up to date software and would install (for example) CoolNewApp 3.7 over CoolNewApp 3.6, since it's not immediately obvious that 3.7 would be unstable.
Zifre
Usually, the versioning policy for any given project is well-documented. Also, I don't see how using Greek letters is somehow more intuitive than using Arabic numerals.
Jörg W Mittag
+1  A: 

GTK+ and GNOME also use that versioning scheme. Note that ruby does not use this scheme anymore since 1.9 (which is stable).

sepp2k
Thanks for the info about Ruby. Apparently people are dropping off this convention.
Ionuț G. Stan
Actually, the reason why the release numbering scheme in Ruby was changed, is even more obscure: when doing a simple lexicographic string compare, "1.10" sorts *before* "1.8", so it was decided to release what *would have been* 1.9.x as 1.9.0-x (so, e.g. what would have been 1.9.2 became 1.9.0-2) and what would have been 1.10.x as 1.9.x+1 (so, e.g. what would have been 1.10.1 became 1.9.2). Thus, the first stable release of Ruby 1.9 was not Ruby 1.9.0 (released Christmas of 2007) but Ruby 1.9.1 (released February 2009).
Jörg W Mittag