[lang]

Present Perfect

Personal
Projects
Packages
Patches
Presents
Linux

Picture Gallery
Present Perfect

nano version numbers

Filed under: Hacking — Thomas @ 9:32 pm

2004-8-5
9:32 pm

Rich Burridge rants about nano version numbers.

I don’t know what project Rich encountered having this, but I’ll share my take on it.
In GStreamer, and these days in a lot of projects I work on, we use nano numbers, but in a very specific way.
First of all, any tarball with a nano number is never an “official” release.
Second, a nano of 1 indicates that “this project is in free-for-all CVS mode, between two releases”. As soon as a release is made, the nano number gets bumped to 1.
Third, a nano bigger than 1 (2 .. infinity) indicates a prerelease. This is a tarball specifically meant to be tested as an alpha/beta/rc/whatever for the final release.
The final release will have a major.minor.micro version. Internally, the nano is 0, and externally, it’s never visible.

This sounds elaborate but works really well in practice.

There are various reasons for why I do this. An important one is that I feel that “official” tarballs should come from one source only, and be used as such. I don’t want someone taking our current CVS, roll a tarball of it, and because I haven’t updated the versioning of my project the tarball ends up with the same name as my last release. And then it gets packaged, and put out in the wild, and people file bugs, and I can’t for the live of me figure out why their x.y.z version asserts in some piece of code that isn’t even in our official x.y.z release. Worse, if I had bumped the micro number after releasing, people would be having tarballs in the wild of what would look like our next release !

A second reason is that some bugs or problems are version-related or release-related. Increasing the version by bumping
the nano brings out bugs that would otherwise have been brought out only when you did your final release. Some bugs are directly tied to your versioning. Others are just simply bugs that you don’t get around to fixing until when you mentally get into release mode. For example, the first thing I do after a prerelease is drag it through a complete package build cycle.

This is usually the time when I notice silly stuff like headers not being installed correctly, plugins having the wrong name, duplicates, … Our GStreamer debian maintainer somehow manages to each time only start building packages a week after release, hence he gets himself into trouble with bugs and issues that he could just as well have fixed properly for the release by testing the prerelease (Why he repeatedly chooses to shoot himself in the foot I don’t know :) Lord knows I’ve tried to psycho-analyse this behaviour in the past…)

Using this scheme avoids the notorious brown-paper-bag-release syndrome. I’m not saying we don’t run into that anymore, but the frequency is a hell of a lot less.

At one point someone released one of my modules because people felt it had a brown paper bag and they couldn’t reach me right away, so they felt it was wise to release because they were impatient, and they chose (horrors) to add a .1 nano. Oh, the humiliation :)

A third reason is that I absolutely abhor having letters in versions. alpha, beta, gold, pl, rc, cvs, try2, pre, … I’ll never use them. They screw up ordering (order these modifiers by implied age), introduce bugs in code (compare handling in different versions of rpm), are ambiguous, and are a pain in the ass for packagers (take a look at the huge volume of threads on fedora.us packaging guidelines). Versions are meant to imply a clear order, and letters get in the way.
(Even worse is when they make you look stupid – one project we use has had an rc5 tarball as their latest release for over two years. Another project you might know has released a tarball with version 1.0pre3try2. And don’t get me started on avifile).

So anyway, far too long of an explanation, but here are my reasons. Are there drawbacks to this system ?

Sadly, yes. There’s one thing I am unhappy with. If you’re about to increase your major.minor pair because you’re going to release an x.y.0 release, you do a prerelease of the x.y-1.z series. This doesn’t help you shake out bugs related to the minor being y and not y-1. But I’ve learned to live with it :)

Anyway, Rich, please point me to those other projects, I’m curious.

Please move along now.

No Comments

No comments yet.

RSS feed for comments on this post. TrackBack URL

Sorry, the comment form is closed at this time.

picture