lkml.org 
[lkml]   [2008]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: From 2.4 to 2.6 to 2.7?
    [Linus Torvalds - Mon, Jul 14, 2008 at 07:22:04PM -0700]
    |
    |
    | On Mon, 14 Jul 2008, Stoyan Gaydarov wrote:
    | >
    | > Second I wanted to talk about the linux 2.7.x kernel, whats in the
    | > making or maybe even not started
    |
    | Nothing.
    |
    | I'm not going back to the old model. The new model is so much better that
    | it's not even worth entertaining as a theory to go back.
    |
    | That said, I _am_ considering changing just the numbering. Not to go back
    | to the old model, but because a constantly increasing minor number leads
    | to big numbers. I'm not all that thrilled with "26" as a number: it's hard
    | to remember.
    |
    | So I would not dismiss (and have been thinking about starting) talk about
    | a simple numbering reset (perhaps yearly), but the old model of 3-year
    | developement trees is simply not coming back as far as I'm concerned.
    |
    | In fact, I think the time-based releases (ie the "2 weeks of merge window
    | until -rc1, followed by roughly two months of stabilization") has been so
    | successful that I'd prefer to skip the version numbering model too. We
    | don't do releases based on "features" any more, so why should we do
    | version _numbering_ based on "features"?
    |
    | For example, I don't see any individual feature that would merit a jump
    | from 2.x to 3.x or even from 2.6.x to 2.8.x. So maybe those version jumps
    | should be done by a time-based model too - matching how we actually do
    | releases anyway.
    |
    | So if the version were to be date-based, instead of releasing 2.6.26,
    | maybe we could have 2008.7 instead. Or just increment the major version
    | every decade, the middle version every year, and the minor version every
    | time we make a release. Whatever.
    |
    | But three-year development trees with a concurrent stable tree? Nope. Not
    | going to happen.
    |
    | Linus
    |

    Hi to all! Since I've been Cc'ed :) I think I'm not the right person
    to be asked about numbering scheme (and since I'm not that long in
    kernel) BUT actually I think there is only one question - it's not
    about how to number the kernel but rather what we trying to say by
    numbering scheme. Some areas should be distinguished:

    - development/stable team
    - distros
    - regular users

    Most developers work with git trees and rather carries about sha1 then
    a version number :) So eventually numbering scheme is not that important
    for developers by its own.

    Distros - well, i think distros use they own scheme anyway so they don't
    really care about kernel versioning scheme (Gentoo-2008, Fedora-9, Ubuntu-8.04...)

    So we have the quite large group of people which should be considered for
    convenient versioning scheme - _regular users_. Lets say I'm a regular user -
    the most convenient scheme for me would be YYYY.r.s i think since it tells
    me - this kernel is fresh enough to be used on my shining laptop, and maybe
    it even supports all hardware I have! And at least it looks good -

    Linux-2008.0.0

    but personally i don't really care that much :)

    - Cyrill -


    \
     
     \ /
      Last update: 2008-07-15 16:27    [W:0.024 / U:0.440 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site