2.6.x-rc0

Responding to the 2.6.32-rc3 announcement, Len Brown noted that, as far as the version number is concerned, there is no difference between (say) 2.6.31 and a kernel checked out near the end of the 2.6.32 merge window, despite the fact that those two kernels differ significantly from each other. Len had a simple request:

Others echoed this request, but Linus made it clear that he was not interested in this idea:

So what is the problem with the -rc0 idea? It turns out there are a few, one of which being that there is already a much more flexible mechanism built into the kernel build system. If the LOCALVERSION_AUTO configuration option is set, the extra version information will be set in a more specific manner. Your editor, who has not been at home long enough to install a new kernel on his desktop for a bit, is currently running a kernel which reports its version as:

    2.6.31-rc5-00002-g3ce001e

It says that the kernel is the one found at git commit ID g3ce001e; the 00002 indicates that it is two commits after 2.6.31-rc5. This version number makes the exact kernel being run clear in a way that a simple makefile tweak would not. Even if -rc0 were really indicative, it would not really say which kernel was being run.

It gets worse than that, though, especially when developers start bisecting kernels to track down bugs. Consider this example: the two post-2.6.31-rc5 commits in your editor's kernel are a pair of BKL-removal patches which fell through the cracks and didn't make the 2.6.32 merge window. Assuming they make it into 2.6.33, the (simplified) git revision history will look something like this:

A developer trying to use bisection to find a problem in 2.6.33-rc1 might well end up at your editor's commit g3ce001e - as a stopping point, of course; that commit could not possibly be the cause of the problem. Should that developer look at the kernel version number at that point, they will not see 2.6.33-rc0 (even if Linus were to make that change) or even 2.6.32 - the version will be 2.6.31-rc5, the version that particular commit is based on. In the git era, kernel development is not a straight-line affair.

What this implies is that anybody who depends on the kernel version number as found in the Makefile is likely to end up confused. There is, of course, one important exception: that number is meaningful only for the actual release it represents. At any other time, it is an unreliable guide.

That doesn't change the fact that people are getting confused by running a kernel which identifies itself as 2.6.x, but which is really closer to 2.6.x+1. So it seems likely that a couple of things will be done to help. One of those is to make the LOCALVERSION_AUTO option enabled by default, and, possibly, difficult to disable. The other is to add some smarts to the build system which tries to check whether the kernel being built differs from the one which was tagged with the official release number. If that is the case, a simple "+" is appended to the version number. So a kernel checked out in the middle of the 2.6.33 merge window would identify itself as 2.6.32+.

Linus doesn't much like that last option (he sees it as losing a lot of information that the full LOCALVERSION_AUTO option provides), but he "doesn't hate" it either. He actually managed to not hate the idea enough to put together a patch implementing it. It has not been merged as of this writing; there is still some discussion happening about possible changes to the LOCALVERSION_AUTO format. But it seems likely that something along these lines will go in during the 2.6.33 merge window, if not before.