[lkml]   [2005]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRFD: Kernel release numbering

    This is an idea that has been brewing for some time: Andrew has mentioned
    it a couple of times, I've talked to some people about it, and today Davem
    sent a suggestion along similar lines to me for 2.6.12.

    Namely that we could adopt the even/odd numbering scheme that we used to
    do on a minor number basis, and instead of dropping it entirely like we
    did, we could have just moved it to the release number, as an indication
    of what was the intent of the release.

    The problem with major development trees like 2.4.x vs 2.5.x was that the
    release cycles were too long, and that people hated the back- and
    forward-porting. That said, it did serve a purpose - people kind of knew
    where they stood, even though we always ended up having to have big
    changes in the stable tree too, just to keep up with a changing landscape.

    So the suggestion on the table would be to go back to even/odd, but do it
    at the "micro-level" of single releases, rather than make it a two- or
    three-year release cycle.

    In this setup, all kernels would still be _stable_, in the sense that we
    don't anticipate any real breakage (if we end up having to rip up so much
    basic stuff that we have to break anything, we'd go back to the 2.7.x kind
    of numbering scheme). So we should fear odd releases, but track them, to
    make sure that they are good (if you don't track them, and problems won't
    be fixed in the even version either)

    But we'd basically have stricter concerns for an even release, and in
    particular the plan would be that the diff files would alternate between
    bigger ones (the 2.6.10->11 full diff was almost 5MB) and smaller ones (a
    2.6.11->12 release would be a "stability only" thing, and hopefully the
    diff file would be much smaller).

    We'd still do the -rcX candidates as we go along in either case, so as a
    user you wouldn't even _need_ to know, but the numbering would be a rough
    guide to intentions. Ie I'd expect that distributions would always try to
    base their stuff off a 2.6.<even> release.

    It seems like a sensible approach, and it's not like the 2.4.x vs 2.5.x
    kind of even/odd thing didn't _work_, the problems really were an issue of
    too big granularity making it hard for user and developers alike. So I see
    this as a tweak of the "let's drop the notion althogether for now"
    decision, and just modify it to "even/odd is meaningful at all levels".

    In other words, we'd have an increasing level of instability with an odd
    release number, depending on how long-term the instability is.

    - 2.6.<even>: even at all levels, aim for having had minimally intrusive
    patches leading up to it (timeframe: a week or two)

    with the odd numbers going like:

    - 2.6.<odd>: still a stable kernel, but accept bigger changes leading up
    to it (timeframe: a month or two).
    - 2.<odd>.x: aim for big changes that may destabilize the kernel for
    several releases (timeframe: a year or two)
    - <odd>.x.x: Linus went crazy, broke absolutely _everything_, and rewrote
    the kernel to be a microkernel using a special message-passing version
    of Visual Basic. (timeframe: "we expect that he will be released from
    the mental institution in a decade or two").

    The reason I put a shorter timeframe on the "all-even" kernel is because I
    don't want developers to be too itchy and sitting on stuff for too long if
    they did something slightly bigger. In theory, the longer the better
    there, but in practice this release numbering is still nothing but a hint
    of the _intent_ of the developers - it's still not a guarantee of "we
    fixed all bugs", and anybody who expects that (and tries to avoid all odd
    release entirely) is just setting himself up for not testing - and thus


    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: 2009-11-18 23:46    [W:4.057 / U:0.072 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site