Messages in this thread | | | Date | Sat, 18 Oct 2008 09:38:10 +0200 | From | Dominik Brodowski <> | Subject | 2.6.28-rc1 --> 2.8.0-rc1; 2.6.27.y --> 2.6.28 [Re: [RFC] Kernel version numbering scheme change] |
| |
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.
| |