If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

In a numbering system sense it wouldn't be the best idea, but I think it would be hilarious if he changed the next kernel version to 2.7 as a way of poking fun at SCO's ridiculous argument years ago that code for the Linux 2.7 kernel was stolen from them.

Comment

i don't understand exactly why they skip over odd numbers (2.7 and 2.9) and imo, if they were going to move to 2.8.0 or 3.0.0, they should have done that when ditching HAL for udev. to me, that was a pretty big change for the kernel. i feel like new version numbers are just thrown out arbitrarily and i really don't like it - except for the very last digit, there doesn't appear to be any particular meaning to any of the numbers.

i agree with the guy who wants to do version numbers by date. considering linux has been stable for about a full decade, we're just going to either go up in little increments like 2.6.37, .38, .39, .40, and so on, or, we're going to go up from 2.6.40 to 3.0.0 without any particular reason.

i feel like 2.7 should be the next number, and 2.7 should not be breached until all KERNEL related current issues (such as the power regression) are fixed. but like stated before, we should have been in 2.7 a long time ago when HAL was replaced.

Comment

The current version number scheme is wrong anyway. With the model now used by the kernel, it makes more sense to release the next version as 2.7.0 and drop the fourth number completely. What use does it have anyway? After 2.7.0 is released, merge window for 2.8.0 opens, and updates to the current stable kernel should be tagged as 2.7.1, 2.7.2, etc.

Edit:
Also, they shouldn't be afraid to increase the major number. For example, removing the BKL was big enough of a change to go to 3.0.0.

Yes something as major as removing the BKL code or major infrastructure/ABI changes should warrant a major version bump. It should have been considered before, as even the 2.4 series has like 37 revisions already.

Comment

i don't understand exactly why they skip over odd numbers (2.7 and 2.9)

Historically, the odd minor revision numbers were the unstable releases where new features would be introduced. ALSA, for example, was introduced in the 2.5 series, then became part of the stable 2.6 kernel. Now that new features are regularly introduced to the kernel, this may change.

Comment

Whenever there were major kernel changes in the past Linus never thought it was necessary to bump the major version number. But now when there are no major changes he wants to change to major version number because "the voices in his head" tell him so? Wtf?

Talk about irrational behavior.

And why is it that whenever Linus travels abroad everybody else has to adjust to that?

No wonder the Android developers and so many others shun upstream development and prefer to work on their own copy of the kernel, where they are not subject to the whim of this dictator.

I'm looking forward to the day when there can be some sanity to Linux kernel development. But I'm afraid it will be a long wait. Linus will never step down, his ego is just too big, and everybody else is either afraid of him or think he's some holy god.

Comment

The name does not matter much, maybe a few scripts need changes that test for 2.6 or 2.4. But new distributions usually don't check this anymore as 2.4 support is not available anyway. So if he wants a new version i have got nothing against it. It does not matter for me how the thing is called.