Version numbering madness

Posted 28 Feb 2000 at 15:31 UTC by Uruk Share This

Most people are familiar with "Major level"."Minor Level"."Patch Level" version numbering, but is this form of version numbering *really* all that important?

A small story to illustrate what I'm trying to get at with this article...

A while back, I got an email from a user of one of the projects that I contribute code to. At the time, the project's latest released version was 0.9. The basic jist of the email was that the project had existed for close to a year, and it had fairly good features, good stability, and was being used. The user then told me that I should go ahead and hurry up and release a 1.0 version, since having the project sitting in a pre-1.0 phase was hurting the credibility of the program.

Hurting the credibility of the program???

I'm not sure what he meant, but when I first read that, my impression was to reject it out of hand. Projects like Enlightenment, Window Maker, and many other well-known software packages that aren't anywhere close to version 1.0 have been out there for quite a while, and don't seem to have suffered any in the credibility department. In fact, they're included as standard software inside Linux distributions that are meant for "production" work. Red Hat and many other distributions include Enlightenment as one of the choices for a default window manager, yet it's only versioned at DR 0.16.3 currently. (and Red Hat hasn't even included the most recent version - but that's another story)

As it has been explained to me, a major level, (i.e. version 1.0) has several characteristics. It should contain as few known bugs as possible, (none at all is very ambitious, as I think most developers would agree) none of which should be "severe". It should probably implement at least the majority of the spec for what the program was originally intended to do, and it should be reasonably thoroughly tested. Whether or not other developers feel the same way about the "criteria" for a version 1.0 release is something I do not know. This is what I told the user who sent me that email. Within the framework of the way that software was being version numbered, it didn't make any sense to arbitrarily say "We're tired of being considered 'beta' or 'alpha' software just because of our version number, so we'll fix a few bugs and slap a '1.0' label on it."

I've also gotten flak from different people around the internet because the versioning scheme hasn't suited various people. Most developers are familiar with GNU version numbering (major.minor.patch) and similar systems. There are a lot of other systems that are similar, some with rules that are agreeable, but essentially arbitrary. The system makes sense in and of itself, it is internally consistent, but as far as the nitpicky rules, it really is arbitrary. And if both your system and mine are arbitrary, yet internally consistent, who's to say your version is 'better' than mine or 'more correct' or vice versa? For example, when dealing with Linux kernels, any minor number that is even corresponds to a stable kernel, and an odd minor number corresponds to a development kernel. A lot of projects don't do it that way though. For me though, the important part about the kernel versioning system is that everybody knows what the rules are and how version numbers are determined, which means that you can look at a version number and know if the software is worth upgrading. I'm running linux-2.2.13 at home. I know that linux-2.2.14 is now available at kernel.org, but since it's only a patchlevel, I can usually safely assume that all that really changed was a fix for the GraphicsFoo accelerator card (with extreme bogon particle emission fixes), which I don't really care about, since I don't have a GraphicsFoo card.

And then there's the confusion in some new users about how most version numbers are NOT floating point numbers. For example, a new Linux user that I know recently asked me why a project recently went from version 0.9 to 0.10. That seems like a huge backward leap, right? But version numbers aren't floating point numbers, so actually, 0.10 is a minor number higher than 0.9, not 8 minor levels lower than 0.9.

Is structured version numbering really all that important? It would be nice if everyone would stick to one well-defined format, but as a user (or a developer), as long as I'm familiar with the way things are done in a project, I personally don't really care how version numbering is done as long as it's clear from one release to the next that progress was made. A good ChangeLog helps too, since that way as a user I can look into the innards of the program and find out if something obscure and totally irrelevant to my usage got changed, or if large structures changed that affect the way the program operates. I don't really feel that it's realistic to expect all or even most projects to use one form of versioning, but I wanted to open it up to other advogato readers to hear about bad/good/indifferent experiences with version numbering and whether or not it's even an issue that needs to be addressed.


Version numbers can indicate stability, posted 28 Feb 2000 at 21:32 UTC by AlanShutko » (Journeyer)

In two major ways.

First, they can indicate how much a program can be expected to crash. The two programs you've mentioned, Enlightenment and WindowMaker, have had a bunch of bugs while I've been using them. I haven't used E recently, but WindowMaker crashed enough that I was glad it got the segfault handler so I could automatically restart it. While it's certainly usable, it's not as rock solid as I would expect from a mature program.

The other way a version number can indicate stability is by showing where a program is in its lifecycle. Most programs that have a version less than 1.0 are under fairly heavy development. A user may have to put forth some effort to keep up with it. But once it hits 1.0, the user has a stable platform that they shouldn't need to upgrade much (ie, showstopper bugs are pretty much absent).

When to declare 1.0? Well, I don't think a program has to have all the features it'll eventually have. I like to think of a set of base features that makes the program usable, and set that as my 1.0 target. (Those who've seen my release history know that I'm still overly optimistic.) Features beyond that can wait for 2.0.

GNU version number standard?, posted 28 Feb 2000 at 23:10 UTC by dan » (Master)

In my capacity as amateur GNU historian (who wasn't even there at the time)

Changes in Emacs 13

* There is a new version numbering scheme.

What used to be the first version number, which was 1, has been discarded since it does not seem that I need three levels of version number.

However, a new third version number has been added to represent changes by user sites. This number will always be zero in Emacs when I distribute it; it will be incremented each time Emacs is built at another site.

According to the original scheme, then, I'm now running emacs 1.20.5.2 Looks more like a CVS revision number than a release, really ...

If RMS can flout version number convention, I think anyone else ought reasonably to be able to get away with it too.

Taking the cake, posted 29 Feb 2000 at 13:16 UTC by Iain » (Master)

we have....Binutils, currently at Version 2.9.5.0.27
What does that all mean?

When will Linux 7.0 be out?, posted 29 Feb 2000 at 19:14 UTC by prozac » (Journeyer)

There is that user perception of versions to deal with. But that is a documentation issue. Jabber is a reality at 90% done!

Here are some thoughts:

  • Users should not dictate version numbers
  • Programs should not be released if not ready
  • Alpha/Beta code should be clearly indicated
  • People should not be too eager to release programs/code
  • Pre-release programs/code only for testing and review
  • Re: When will Linux 7.0 be out?, posted 1 Mar 2000 at 12:08 UTC by ajkroll » (Journeyer)

    I agree with evertyhing said. Especially:

    - People should not be too eager to release programs/code

    I tend to actually hold any of my own releases and test them on my own crash boxes as well as a small group of gunia pigs that may want to give it try. This hold time can sometimes be 6 months untill I feel it is secure enough and well put thru it's paces.

    What I find extremely hillarious is people who have been basically brainwashed into thinking that they absolutly MUST have the latest software revision, even if what they have works well and gets done what they need to get done. This tends to put unfair pressure on the developers of the program, early releases with bugs or other anomolies. On my own system, I *STILL* have programs that are a.out and are fully secure and functional. I don't even have glibc on it (yet) because I haven't had a seriously compelling need for it, and glibc seems to have a problem with group permissions (ahem). Same for word processing... how many people aimlessly grab the absolute latest GUI for word processing? Why bother? I am happy with WordStar 2.26 on a CP/M machine. You know what? The output on the inkjet printer is no different than GUI word processing programs. :-)

    Netizens:

    My point is simple. If it works, don't fix it, especially if it is pay software. If you need newer fetures and absolutly can't live without them, upgrade, but procede with caution (and a backup of the one that actually worked in the first place). Don't upgrade just to feel cool, you might end up getting nipped in the butt.

    Developers:

    If your going to release something, make sure the damn thing actually installs. Try and provide your intended audience with some kind of painless options file upgrade script too. I realize the pains of this, honest, however it can be done very cleanly and simply. Think about this angle:

    If the last version parsed the rc file, why can't you parse it into the new format?

    Makes sense to me...

    TEST it ... then....

    TEST IT AGAIN!!!... then....

    Have a few other people test it. You *NEVER* can be certain how it might or might not interact or react to all the madness on someone else's system, especially someone's usage patterns, hand edited rc files, and so-on.

    It's how I do it, and why all my code is of quality, not quantity.

    ajk

    Here's one for you, posted 3 Mar 2000 at 04:32 UTC by doylep » (Journeyer)

    The SmallEiffel compiler started from version -1.0, and has been counting upward (toward zero). They are currently at version -0.77. Go figure.

    something else to keep in mind, posted 7 Mar 2000 at 01:10 UTC by joey » (Master)

    I'd tend to agree that version numbering consistency accross projects doesn't matter much. One thing that does matter is that the version numbers should be easily machine-comparable -- otherwise tools like rpm and dpkg don't work very well and various hacks have to be used in packages.

    Quoting the Debian packaging manual:

    (the author of this manual has heard of a package whose versions went `1.1', `1.2', `1.3', `1', `2.1', `2.2', `2' and so forth)
    Clearly that type of thing is Evil.

    Version numbers are marketing, posted 4 Apr 2000 at 07:12 UTC by softweyr » (Master)

    No more, no less. They convey little information of real value to the user, other than version 0.61.2 is assumed to be somewhat newer than version 0.59.4. Various development teams and marketing organizations (yes, free software has marketing also, it's just not very good nor very well thought out) assign different meanings to various version numbers, almost willy-nilly.

    New Advogato Features

    New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

    Keep up with the latest Advogato features by reading the Advogato status blog.

    If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

    X
    Share this page