Linus Torvalds is thinking about changing the Linux kernel version numbering scheme [Kernel Release Numbering Redux]. He said: “I _am_ considering changing just the [version] numbering… because a constantly increasing minor number leads to big numbers. I’m not all that thrilled with ‘26’ as a number: it’s hard to remember… If the version were to be date-based, instead of releasing 2.6.26, maybe we could have 2008.7 instead… I personally don’t have any hugely strong opinions on the numbering. I suspect others do, though, and I’m almost certain that this is an absolutely _perfect_ ‘bikeshed-painting’ subject… let the bike-shed-painting begin.”
Here’s my proposal: Offset 2000 version numbers, i.e., “(y-2000).mm[.dd]”. The first number is the year minus 2000, followed by “.” and a two-digit month, optionally followed by “.” and a two-digit day when there’s more than one release in a month. So version 8.07 would be the first release in July 2008. If you made a later release on July 17, that later release would be 8.07.17 (so if a project makes many releases in a month, you can again determine how old a particular copy is).
Date-based version numbers have a lot going for them, because at a glance you know when it was released (and thus you can determine how old something is). If you choose the ISO order YYYY.MM.DD, the numbers sort very nicely; Debian packages often use YYYYMMDD for versioning. But there’s a problem: full year numbers, or full dates in this format, are annoyingly large. For example, version numbers 2008.07.16 and 20080716 are painfully long version numbers to remember.
So, use dates, but shorten then. Since nothing today can be released before 2000, shorten it by subtracting 2000. Note that this is subtracting - there’s no Y2K-like rollover problem, because the year 2100 becomes 100 and the year 3000 becomes 1000. The second number is the month; using a two-digit month means you don’t have the ambiguity of determining if “2.2” is earlier or later than “2.10” (you would use “2.02” instead). If you need to disambiguate day releases (or you make additional releases in the same month), add “.” and a two-digit day.
These version numbers are short, they’re easy to compare, and they give you a clue about when it was released. Ubuntu already uses this scheme for the first two parts, so this scheme is already in use and familiar to many. This works perfectly with “natural sort” (e.g., with GNOME’s Nautilus file manager or with GNU ls’s “-v” option).
If you use a time-based release system (see this summary of Martin Michlmayr’s thesis for why you would), using this version numbering scheme is easy, and you can even talk about future releases the same way. But what if you release software based on when the features are ready - how, then, can you talk about the system under development? In that case, you can’t easily call it by the version number, since you don’t know it yet. But that’s not really a problem. In many cases, you can just talk about the “development” branch or give a special name to the development branch (e.g., “Rawhide” for Fedora). If you need to distinguish between multiple development branches, just give each of them a name (e.g., “Hardy Heron” for Ubuntu); on release you can announce the version number of a named branch (e.g., “Hardy Heron is 8.04”). This is more-or-less what many people do now, but if a lot of us used the same system, version numbers would have more meaning than they do now.
path: /oss | Current Weblog | permanent link to this entry