When Linus announced
the 3.0-rc1 kernel at
the end of May, he noted that it was actually identifying itself as
"3.0.0". There were enough scripts out there expecting that third digit to
exist that he didn't want to break them from the outset. Still, he was
hopeful that the final ".0" could go away:
We'll have the usual 6-7 weeks to wrestle it into submission, and
get scripts etc cleaned up, and the final release should be just
"3.0". The -stable team can use the third number for their
Fast forward to 3.0-rc7, and the kernel is still identifying itself as
3.0.0. While hard information is relatively scarce, it seems that there
are still some programs and scripts out there that will break without
that final number. In a sense, the three-number versioning scheme has
become a part of the kernel ABI over the years. One can argue that
anything which breaks was written in a silly way to begin with, but the
goal is still to avoid breaking user space. So, while no definitive answer
has been given, it looks like we're going to have three-number mainline
releases for some time. It would be most surprising to see the stable
updates starting with anything other than 3.0.1, though.
There is one related question, though: what about programs that cannot
cope with anything other than "2.6.x" as the kernel version number?
Evidently such programs exist. Saying that kernel releases must start with
"2.6" forevermore stretches even the firmest commitment to binary
compatibility; it's not something that is going to happen. In an attempt
to make life easier for people stuck with such programs, Andi Kleen has
implemented a new system personality that
pretends the 3.0 change never happened. If a program is run under that
personality, it will think that the kernel version is 2.6.40; 3.1 will look
like 2.6.41, etc.
Andi says "I know this is somewhat ugly, but I didn't find a better
workaround, and compatibility to existing programs is important."
As of this writing, though, the patch has not made it into the mainline.
to post comments)