(Short?) merge window reminder
A new major version number will reach high expectations. I think it's better to wait till the power issues of 2.6.38/39 are fixed and proved to be absent, before naming it Linux 3.0.
Anyway, wouldn't it be a great date to release Linux 3 on August 21, 2011? I know it's hard to achieve this exact date with a stable 3.0. If you don't think a fixed date for a stable version is a good idea, you could release the first RC of 3.0 on that date.
About the scripts: if they don't like the version number to be 1 digit shorter, why not append an extra .0 to uname? This digit can be used for bugfix releases, like 2.6.38.7. In the current system, an extra digit is added for those releases. But if that extra digit will always be there, and is 0 by default, scripts won't care about the lack of a 3rd digit. Then, the 3.0 will be 3.0.0, with new releases (current 3rd digit) being 3.1.0, 3.2.0, ..., and bugfix releases (current 4th digit) being 3.0.1, 3.0.2, .... It might be a bit confusing after the switch, but if we change to a 2-digit number, it's confusing too. Scripts recognizing bugfixes as new releases is a smaller disaster than scripts crashing or returning errors due to the lack of a 3rd digit.
I agree with Jon Smirl that it could be probably better to release 2.8 first, but there's also a good side on switching to 3.0. We are skipping 2.7, that means our version numbering system already changes a bit. Why not change it completely then?
Sorry if I've missed out some discussion about this, I am not subscribed. I have only read some messages in the LKML archive.
Albert Pool
On Tue, May 24, 2011 at 15:48:39 +0100, Ralf Baechle wrote:
Quoted 8 lines · Ted Ts'o
Quoted 3 lines
So I'm toying with 3.0 (and in that case, it really would be "3.0", not "3.0.0" - the stable team would get the third digit rather than the fourth one.
If we change from 2.6.X to 3.X, then if we don't change anything else, then successive stable release will cause the
LINUX_VERSION_CODEto be incremented. This isn't necessary bad, but it would be a different from what we have now.
It will require another bunch of changes to scripts that try to make sense out of kernel Linux version numbers. It's a minor issue and we might be better off doing something else than version number magic. Not last a new major version number raises expectations - whatever those might be.
Ralf