Re: [PATCH-RFC] 4 of 4 - New problem logging macros, SCSI RAIDdevice driver

[Denis Vlasenko]

On 28 September 2002 07:16, jw schultz wrote:
> Ingo, I agree with Linus.  My recollection of when we moved
> to 2.0 was that the major number reflected the user<->kernel
> ABI.  I have no problem with a version 2.42 if things stay
> stable that long.   I hope they don't but that is another
> issue.
>
> Version 3.0 implies incompatibility with binaries from 2.x
> The distributions can play around with version numbers
> reflecting the GUI interface, libraries or installers but
> the kernel major version should stay the same until binary
> compatibility is broken.  When we move old syscalls (such as
> 32 bit file ops) from deprecated to unsupported is when we
> increment the major number.
>
> It may be that 2.7 will see the cruft cut out and be the end
> of 2.x but 2.5 isn't that.  So far 2.5 is performance
> enhancement.  Terrific performance enhancement, thanks to you
> and many others.  But it isn't adding major new features nor
> is it removing old interfaces.  In many ways 2.6 looks like
> a sign that the 2.x kernel is getting mature.  2.6 means
> users can expect improvements but don't have to make big changes.
> 2.6 is an upgrade, 3.0 would be a replacement.

Technically correct. Major version jump should be made when there is
a binary incompatibility. It can be made without, but it is usually
done for marketing reasons. I hope we'll never have marketing reasons
for lk. :-) We can be actually _proud_ to have 2.$BIGNUM instead of
3.0
--
vda