The feature freeze is coming

Major version number change happened exactly once previously, so there is nothing wrong to define it in any way Linus wants. And, indeed even 2.0 -> 2.2 or 2.2 -> 2.4 requires some user-level incompatible API changes (especially when we talk about the /proc filesystem). On the other hand, the system call interface had been very stable (only addition, no major change in semantics) because everything becomes a new syscall rather than redefine an old one (you find a getuid for 16 bits UID and another for 32 bits one). "Major number changes means API (or even ABI) changes" works for applications, but not the kernel.

These sorts of changes build up over time, and it doesn't make sense to only consider the incremental effect; after a while it becomes clear that there are major differences, even if you can't point to a time when they all happened (in fact, Linux should probably never have a release where everything changes at once, since that would be overly disruptive and very difficult to debug). The differences introduced in 2.5 don't seem that major, but there are many substantial differences since 2.0. When writing code for 2.5, you're likely to want to have many threads, to take advantage of SMP, to avoid large select/poll, and so forth. On 2.0, SMP wasn't really worth coding for, and select was the most efficient way to deal with multiple IO streams, since multiple processes for a single purpose were inefficient.

Furthermore, I think it is a good idea to have interfaces deprecated for an entire major version before they are removed. When you clean out the old APIs in bulk, you want a clear mark for when the APIs you're removing were deprecated. You don't want to remove all of the deprecated interfaces, including the ones you deprecated the day before and everybody is still using. If you include signalling your intention to remove interfaces as an API change (since people will hopefully change even code that currently works in response), it's probably time for a new major version.

3.0

The left side of my brain says 2.6. Although the improvements are significant, they are still incremental. There's no technical reason to make concessions based on people's infatuation with round numbers.

On the other hand, 2.6 is just a number, like 3.0 or 3.1001 or 7.0. If Sun can jump Solaris from 2.6 to 7.0 in one release, I don't see why Linux can't do the same. I think a 3.0 release would get a lot more press than a 2.6 release. This in itself would seem to make 3.0 a good choice, give the lack of any significant drawbacks.

Perhaps from now on they should all be major number releases. :-)

I couldn't have said it better myself. Don't go to 3.0 unless there is a good reason, and, as many here have said, there isn't a good reason. Let's at least wait until we have an honest-to-goodness not-lame VFS layer before we go trumpeting some great new major number release. I think of 2.6 v. 2.4 the way I think of Windows 98 v. Windows 95: basically a bug fix release, with some major BS (bad stuff), that shouldn't have gone in anyway, cleaned up, and some major good sutff, that should have gone in in the first place, added. Some of which is being back-ported to 2.4 anyway. Yeah, there's some new stuff coming to 2.6, and it's all good, but not enough to be a 3.0. Let's get a real VFS, I'm tired of being embarrassed by that. Once we have that, we can truely put NT and Solaris to bed ~:^)