Alex headshot

AlBlue’s Blog

Macs, Modularity and More

JSR294 Fantasy Version Series - Linux

Java 2009 Jsr294 Eclipse Osgi

Following on from yesterday's Roman Numeral episode, today introduces the Linux versioning scheme. (The kernel; not to be confused with GNU/Linux in case there's some bearded hippie reading this. The next in the series is now available.)

Linux version numbering begins with a 2, and then uses even/odd digits to denote development releases and stable releases. For example, 2.3 reflected a developmental kernel whilst 2.4 was a stable kernel.

After that, there is one (or more) digits that are numerically incremented. For marketing reasons, if a version isn't considered to be 'big enough', then a fourth (or more) digits can be randomly added to the end. This holds true for largely backward compatible changes as well as slightly not backward compatible ones as well.

The versioning format is therefore represented by a regular expressions: for stable releases, the format is 2\.[0-9]*[02468]\.[0-9]+(\.[0-9]+)*, whilst for development releases it is 2\.[0-9]*[13579]\.[0-9]+(\.[0-9]+)*. Users MUST randomly add new digits if, in their belief, it's not really that big a change. Note that this system is infinitely flexible, reaching an epsilon state, so bug fixes involving documentation changes might be represented as After all, it worked for LDAP OIDs.

Fields are decomposed (separated by ., escaped as \. in the regex above) and compared numerically. If digits are missing, they are assumed to be zero. Fields are compared in order; if all one is a proper prefix of the other (i.e. one is a full subset of another, but the other is longer) then length wins, as with other areas of life.

Note that because there are two, overlaid, versioning schemes, whilst it is possible to compare developmental releases to developmental releases (c.f. stable), it is not possible to compare developmental and stable releases. In other words, the comparison function is a partial function over the version namespace; comparisions between developmental and stable are expressly prohibited. Furthermore, version ranges are therefore not considered continuous; the version line of a stable system might be [2.0,3.0) but this is to be interpreted as the union [2.0,2.1),[2.2,2,3), [2.4,2.5) etc. This represents a great advantage over more limited versioning systems which only have three digits and do not consider discontinuous ranges.

We may use this to define module requirements, as in the following non-normative example

module Lenny @ 2.4 {
 requires SMTP @ [2.2,2.5), // But not 2.3, because that's a dev release
 requires MacOSX @ 2.10.*.2+, // Who uses Mac OS X before .2 comes out?
 permits Desmond @ 2.2,

Note: this is not to be confused with "vaguely Debian-like syntax." Debian is a Linux Distribution, not a Linux Kernel, and uses a different versioning scheme.