> On Thu, 3 Oct 2002 jbradford@dial.pipex.com wrote:
> >
> > I think we should stick to incrementing the major number when binary
> > compatibility is broken.
>
> "Stick to"? We've never had that as any criteria for major numbers in the
> kernel. Binary compatibility has _never_ been broken as a release policy,
> only as a "that code is old, and we've given people 5 years to migrate to
> the new system calls, the old ones are TOAST".
Ah, I was getting confused, I thought that the move to 2.0 was when we moved from a.out to elf. I didn't really follow kernel development very closely at all back then, to be truthful.
> The only policy for major numbers has always been "major capability
> changes".
Then it definitely shouldn't be 3.0 yet then.
> 1.0 was "networking is stable and generally usable" (by the
> standards of that time), while 2.0 was "SMP and true multi-architecture
> support". My planned point for 3.0 was NuMA support, but while we actually
> have some of that, the hardware just isn't relevant enough to matter.
Hmmm, then for 3.0 I'd vote for fully working and proven stable:
* High memory support,
* IPV6
* IDE-SCSI
* Bluetooth
* USB (2)
* IEEE 1394
> The memory management issues would qualify for 3.0, but my argument there
> is really that I doubt everybody really is happy yet. Which was why I
> asked for people to test it and complain about VM behaviour - and we've
> had some ccomplaints ("too swap-happy") although they haven't sounded like
> really horrible problems.
To be completely honest, I dont't see any improvement in 2.5.x over 2.4.x on my boxes that are running both :-(.
John.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 07 2002 - 22:00:40 EST