The mislabeling of 2.6.32-rc1 in the makefile might have been the cause of
some confusion, though the skipping of -rc2 will have avoided the worst of
it. But it seems that there is confusion with version numbers at other
times, leading to a push for a change that Linus has absolutely no
intention of making.
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:
This could be clarified if you update Makefile on the 1st commit
after 2.6.X is frozen to simply be 2.6.Y-merge or 2.6.Y-rc0 or
something. Anything but 2.6.X.
Others echoed this request, but Linus made it
clear that he was not interested in this idea:
So no. I'm not going to do -rc0. Because doing that is
_stupid_. And until you understand _why_ it's stupid, it's
pointless talking about it, and when you _do_ understand that it's
stupid, you'll agree with me.
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:
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
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.
to post comments)