2.6.28-rc1 --> 2.8.0-rc1; 2.6.27.y --> 2.6.28 [Re: [RFC] Kernel version numbering scheme change]

[Dominik Brodowski <linux@dominikbrodowski.net>]

On Sat, Oct 18, 2008 at 12:18:58AM -0700, H. Peter Anvin wrote:
> Greg KH wrote:
> >>
> >>I think it's both visually cumbersome and has the problem that it is 
> >>harder to predict future releases.  The first problem can be dealt with 
> >>by simply subtracting 2000 from the year (Altera uses this scheme for 
> >>their EDA tools, and I didn't realize it for quite a while because it 
> >>looked so natural), but the second is still a problem.
> >
> >What is the "problem" of predicting future releases?  What relies on the
> >actual number being "correct" some random time in the future?
> >
> 
> We already have the 2.6.28-rc series; and we are already talking about 
> 2.6.29 features.

Well, Linus hasn't yet changed SUBLEVEL or EXTRAVERSION[*]. But Adrian has
already stated that he will support what is known as 2.6.27 for a long time.
What about Linus naming the next release 2.8.0 (and move on with 2.8.1,
2.8.2, ... with no special meaning to the numbers), so instead of 2.6.28-rc1
it's 2.8.0-rc1. And once Adrian takes over from the -stable team, he could
release 2.6.28, 2.6.29 and so on when he thinks a new minor number is
appropriate, such as Willy intends to release 2.4.37.

Best,
	Dominik


[*] Actually, it might be helpful if the very first commit after a
release were to change SUBLEVEL to the next number and EXTRAVERSION to "pre"
or something else, so that /lib/modules/2.6.y/ and the initramfs isn't then
overwritten by the sometimes rough builds between 2.6.y and 2.6.(y+1)-rc1.