[lkml]   [2002]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [OT] 2.6 not 3.0 - (WAS Re: [PATCH-RFC] 4 of 4 - New problem logging macros, SCSI RAIDdevice)

    On Thu, 3 Oct 2002 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".

    The only policy for major numbers has always been "major capability
    changes". 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.

    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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:29    [W:0.041 / U:1.772 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site