[RFC] Kernel version numbering scheme change - Kernel

This is a discussion on [RFC] Kernel version numbering scheme change - Kernel ; On Sat, 18 Oct 2008, Jan Engelhardt wrote: > On Thursday 2008-10-16 03:34, david@lang.hm wrote: >> On Thu, 16 Oct 2008, Thorsten Leemhuis wrote: >>> On 16.10.2008 02:25, Greg KH wrote: >>> >>> Hence people that write a lot of ...

+ Reply to Thread
Page 5 of 6 FirstFirst ... 3 4 5 6 LastLast
Results 81 to 100 of 111

Thread: [RFC] Kernel version numbering scheme change

  1. Re: [RFC] Kernel version numbering scheme change

    On Sat, 18 Oct 2008, Jan Engelhardt wrote:

    > On Thursday 2008-10-16 03:34, david@lang.hm wrote:
    >> On Thu, 16 Oct 2008, Thorsten Leemhuis wrote:
    >>> On 16.10.2008 02:25, Greg KH wrote:
    >>>
    >>> Hence people that write a lot of articles about things that happen in linux
    >>> land (like LWN.net or I do) would be forced to write sentences like "[...]the
    >>> kernel that will become 2008.3 or 2009.0 will have feature foo that works
    >>> like this[...]". That will get really confusing if you read those articles
    >>> half a year later -- especially if that kernel became 2008.3 in the end,
    >>> because foo in 2009.0 might already look quite different again...

    >>
    >> pick a name when the merge window opens

    >
    > Hell no, we're not a distro.


    huh?

    we are picking the name for the next kernel far more in advance today (we
    know that the next kernel will be named 2.6.28, and the one after thta
    2.6.29)

    I'm just saying, pick the name/number for the kernel based on when the
    merge window opened.

    if it's the first merge window in 2009 the kernel would be 2009.1.0, if
    it's the 5th merge window it would be 2009.5.0, even if the resulting
    kernel ended up getting released in 2010

    David Lang
    --
    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/

  2. Re: [RFC] Kernel version numbering scheme change


    On Saturday 2008-10-18 21:52, david@lang.hm wrote:
    >> >
    >> > pick a name when the merge window opens

    >>
    >> Hell no, we're not a distro.

    >
    > huh?
    >
    > we are picking the name for the next kernel far more in advance today (we know
    > that the next kernel will be named 2.6.28, and the one after thta 2.6.29)


    "name" is not the same as "version". When you say name, I get this:

    $ grep NAME Makefile
    NAME = Rotary Wombat

    and we, hey, we already have names!

    > I'm just saying, pick the name/number for the kernel based on when the merge
    > window opened.


    Yeah. I mean that's how it was done so far
    --
    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/

  3. Re: [RFC] Kernel version numbering scheme change

    On Sun, Oct 19, 2008 at 01:17:19AM +0200, Jiri Kosina wrote:
    > On Sat, 18 Oct 2008, Willy Tarreau wrote:
    >
    > > confusion between 2.4.37 and 2.6.27. I have already tagged kernels with
    > > wrong versions, having to fix by hand afterwards. It's really cumbersome
    > > some times.

    >
    > But this is only because you are maintaining a source code that is several
    > years old, right?


    It has nothing to do with age, but with the number of digits. Having 4 series
    of digits is not easy, especially when some of them are two-digits large.
    2.6.26.25-rc1 and 2.6.25.26-rc1 are obviously confusing and not old (not
    even released).

    > Would maintaining a series numbered 2002.x.y make your
    > situation a lot better? Do you think you'd never make typo '2002 instead
    > of 2006' any more?


    Yes I probably would, and I already said I would not like such a numbering
    which is even worse IMHO. I'm for small number of digits, X.Y[.Z] with both
    X and Y < 10, and Z the stable release. In 22 years, X will go to 10 which
    is still not a problem.

    > Or how would you distingiush the kernel tree you are maintaing from the
    > one Linus is maintaining?


    Another reason why I don't like dates. It makes forked versions more
    confusing. Assuming that in 10 years we get 40 versions further, we
    might be at version 6.8 and maybe I would have switched to maintain
    "old" version 4.2. There is no confusion here.

    BTW, speaking about dates, I noticed that others have experimented
    with dates and finally changed their mind. Even microsoft. Remember
    windows 3.1/3.11 ? In parallel, you had NT 3.5. After that you got
    windows 95 (year of predicted release), then 98 (idem). In parallel,
    NT went to 4.0. Then they merged all of them into windows 2000,
    dropping the versions. Then they started inventing stupid names
    like ME, Xp, Vista, ... and now they're talking about windows 7,
    which should take its version from the kernel, because the kernel
    has kept being versionned "normally" (no marketting involved in
    this area). So they might have noticed that using years makes the
    whole thing more complex for everyone in the long term. They get
    laughed at when releases are delayed, people don't really know if
    their seemingly old "2003" is really old or the last one, etc...

    Probably that using dates in packaged products such as distros
    based on whatever is available at the given date and meant to
    evolve quickly and not being supported for long is good however.
    It's just a snapshot at a given date and nothing more.

    Willy

    --
    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/

  4. Re: [RFC] Kernel version numbering scheme change

    On Sunday, 19 of October 2008, Jiri Kosina wrote:
    > On Fri, 17 Oct 2008, david@lang.hm wrote:
    >
    > > > Surely some scripts will start to break as soon as the third number gets
    > > > three digits.

    > > we've had three digit numbers in the third position before (2.3 and 2.5
    > > went well past three digits IIRC)

    >
    > Did we? I only recall 2.5.7[something] and 2.3.5[something] (plus special
    > 2.3.99 release).
    >
    > > > Actually, I thought we could continue to use a w.x.y.z numbering
    > > > scheme, but in such a way that:
    > > > w = ($year - 2000) / 10 + 2 (so that we start from 2)
    > > > x = $year % 10
    > > > y = (number of major release in $year)
    > > > z = (number of stable version for major release w.x.y)
    > > > Then, the first major release in 2009 would be 2.9.1 and its first
    > > > -stable "child" would become 2.9.1.1. In turn, the first major
    > > > release in 2010 could be 3.0.1 and so on.

    > > if you want the part of the version number to increment based on the year,
    > > just make it the year and don't complicate things.

    >
    > In addition to that, having the kernel version dependent on year doesn't
    > really seem to make much sense to me. Simply said, I don't see any
    > relation of kernel source code contents to the current date in whatever
    > calendar system.
    >
    > And 2.x+1.y-rcZ+1 immediately following 2.x.y-rcZ really hurts my eyes


    Hm, why would that happen?

    Rafael
    --
    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/

  5. Re: [RFC] Kernel version numbering scheme change

    On Sun, 19 Oct 2008, Rafael J. Wysocki wrote:

    > On Sunday, 19 of October 2008, Jiri Kosina wrote:
    >> On Fri, 17 Oct 2008, david@lang.hm wrote:
    >>
    >>>> Surely some scripts will start to break as soon as the third number gets
    >>>> three digits.
    >>> we've had three digit numbers in the third position before (2.3 and 2.5
    >>> went well past three digits IIRC)

    >>
    >> Did we? I only recall 2.5.7[something] and 2.3.5[something] (plus special
    >> 2.3.99 release).
    >>
    >>>> Actually, I thought we could continue to use a w.x.y.z numbering
    >>>> scheme, but in such a way that:
    >>>> w = ($year - 2000) / 10 + 2 (so that we start from 2)
    >>>> x = $year % 10
    >>>> y = (number of major release in $year)
    >>>> z = (number of stable version for major release w.x.y)
    >>>> Then, the first major release in 2009 would be 2.9.1 and its first
    >>>> -stable "child" would become 2.9.1.1. In turn, the first major
    >>>> release in 2010 could be 3.0.1 and so on.
    >>> if you want the part of the version number to increment based on the year,
    >>> just make it the year and don't complicate things.

    >>
    >> In addition to that, having the kernel version dependent on year doesn't
    >> really seem to make much sense to me. Simply said, I don't see any
    >> relation of kernel source code contents to the current date in whatever
    >> calendar system.
    >>
    >> And 2.x+1.y-rcZ+1 immediately following 2.x.y-rcZ really hurts my eyes

    >
    > Hm, why would that happen?


    with the date based numbers, that was one of the things that 'could'
    happen as the year changed (2008.5.0-rc4 would be followed by
    2009.1.0-rc5)

    David Lang
    --
    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/

  6. Re: [RFC] Kernel version numbering scheme change

    On Sun, 19 Oct 2008, Rafael J. Wysocki wrote:

    > On Sunday, 19 of October 2008, david@lang.hm wrote:
    >> On Sun, 19 Oct 2008, Rafael J. Wysocki wrote:
    >>
    >>> On Sunday, 19 of October 2008, Jiri Kosina wrote:
    >>>> On Fri, 17 Oct 2008, david@lang.hm wrote:
    >>>>
    >>>>>> Surely some scripts will start to break as soon as the third number gets
    >>>>>> three digits.
    >>>>> we've had three digit numbers in the third position before (2.3 and 2.5
    >>>>> went well past three digits IIRC)
    >>>>
    >>>> Did we? I only recall 2.5.7[something] and 2.3.5[something] (plus special
    >>>> 2.3.99 release).
    >>>>
    >>>>>> Actually, I thought we could continue to use a w.x.y.z numbering
    >>>>>> scheme, but in such a way that:
    >>>>>> w = ($year - 2000) / 10 + 2 (so that we start from 2)
    >>>>>> x = $year % 10
    >>>>>> y = (number of major release in $year)
    >>>>>> z = (number of stable version for major release w.x.y)
    >>>>>> Then, the first major release in 2009 would be 2.9.1 and its first
    >>>>>> -stable "child" would become 2.9.1.1. In turn, the first major
    >>>>>> release in 2010 could be 3.0.1 and so on.
    >>>>> if you want the part of the version number to increment based on the year,
    >>>>> just make it the year and don't complicate things.
    >>>>
    >>>> In addition to that, having the kernel version dependent on year doesn't
    >>>> really seem to make much sense to me. Simply said, I don't see any
    >>>> relation of kernel source code contents to the current date in whatever
    >>>> calendar system.
    >>>>
    >>>> And 2.x+1.y-rcZ+1 immediately following 2.x.y-rcZ really hurts my eyes
    >>>
    >>> Hm, why would that happen?

    >>
    >> with the date based numbers, that was one of the things that 'could'
    >> happen as the year changed (2008.5.0-rc4 would be followed by
    >> 2009.1.0-rc5)

    >
    > Well, in that case I think it would be reasonable to cuntinue the 2008
    > numbering so that 2009.1.0-rc5 in your example would still be 2008.5.0-rc5.
    >
    > That said, I kind of agree that the numbering need not be time-related. One
    > alternative might be to release 2.9.0 instead of 2.6.29 and then continue in
    > in such a way that each of the three numbers is always a one-digit decimal.
    > Then, we'd have 2.9.0, 2.9.1 ... 2.9.9, 3.0.0, 3.0.1 etc.


    so how would you do the -stable releases?

    David Lang
    --
    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/

  7. Re: [RFC] Kernel version numbering scheme change

    On Sunday, 19 of October 2008, david@lang.hm wrote:
    > On Sun, 19 Oct 2008, Rafael J. Wysocki wrote:
    >
    > > On Sunday, 19 of October 2008, Jiri Kosina wrote:
    > >> On Fri, 17 Oct 2008, david@lang.hm wrote:
    > >>
    > >>>> Surely some scripts will start to break as soon as the third number gets
    > >>>> three digits.
    > >>> we've had three digit numbers in the third position before (2.3 and 2.5
    > >>> went well past three digits IIRC)
    > >>
    > >> Did we? I only recall 2.5.7[something] and 2.3.5[something] (plus special
    > >> 2.3.99 release).
    > >>
    > >>>> Actually, I thought we could continue to use a w.x.y.z numbering
    > >>>> scheme, but in such a way that:
    > >>>> w = ($year - 2000) / 10 + 2 (so that we start from 2)
    > >>>> x = $year % 10
    > >>>> y = (number of major release in $year)
    > >>>> z = (number of stable version for major release w.x.y)
    > >>>> Then, the first major release in 2009 would be 2.9.1 and its first
    > >>>> -stable "child" would become 2.9.1.1. In turn, the first major
    > >>>> release in 2010 could be 3.0.1 and so on.
    > >>> if you want the part of the version number to increment based on the year,
    > >>> just make it the year and don't complicate things.
    > >>
    > >> In addition to that, having the kernel version dependent on year doesn't
    > >> really seem to make much sense to me. Simply said, I don't see any
    > >> relation of kernel source code contents to the current date in whatever
    > >> calendar system.
    > >>
    > >> And 2.x+1.y-rcZ+1 immediately following 2.x.y-rcZ really hurts my eyes

    > >
    > > Hm, why would that happen?

    >
    > with the date based numbers, that was one of the things that 'could'
    > happen as the year changed (2008.5.0-rc4 would be followed by
    > 2009.1.0-rc5)


    Well, in that case I think it would be reasonable to cuntinue the 2008
    numbering so that 2009.1.0-rc5 in your example would still be 2008.5.0-rc5.

    That said, I kind of agree that the numbering need not be time-related. One
    alternative might be to release 2.9.0 instead of 2.6.29 and then continue in
    in such a way that each of the three numbers is always a one-digit decimal.
    Then, we'd have 2.9.0, 2.9.1 ... 2.9.9, 3.0.0, 3.0.1 etc.

    Thanks,
    Rafael
    --
    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/

  8. Re: [RFC] Kernel version numbering scheme change

    On Sunday, 19 of October 2008, david@lang.hm wrote:
    > On Sun, 19 Oct 2008, Rafael J. Wysocki wrote:
    >
    > > On Sunday, 19 of October 2008, david@lang.hm wrote:
    > >> On Sun, 19 Oct 2008, Rafael J. Wysocki wrote:
    > >>
    > >>> On Sunday, 19 of October 2008, Jiri Kosina wrote:
    > >>>> On Fri, 17 Oct 2008, david@lang.hm wrote:
    > >>>>
    > >>>>>> Surely some scripts will start to break as soon as the third number gets
    > >>>>>> three digits.
    > >>>>> we've had three digit numbers in the third position before (2.3 and 2.5
    > >>>>> went well past three digits IIRC)
    > >>>>
    > >>>> Did we? I only recall 2.5.7[something] and 2.3.5[something] (plus special
    > >>>> 2.3.99 release).
    > >>>>
    > >>>>>> Actually, I thought we could continue to use a w.x.y.z numbering
    > >>>>>> scheme, but in such a way that:
    > >>>>>> w = ($year - 2000) / 10 + 2 (so that we start from 2)
    > >>>>>> x = $year % 10
    > >>>>>> y = (number of major release in $year)
    > >>>>>> z = (number of stable version for major release w.x.y)
    > >>>>>> Then, the first major release in 2009 would be 2.9.1 and its first
    > >>>>>> -stable "child" would become 2.9.1.1. In turn, the first major
    > >>>>>> release in 2010 could be 3.0.1 and so on.
    > >>>>> if you want the part of the version number to increment based on the year,
    > >>>>> just make it the year and don't complicate things.
    > >>>>
    > >>>> In addition to that, having the kernel version dependent on year doesn't
    > >>>> really seem to make much sense to me. Simply said, I don't see any
    > >>>> relation of kernel source code contents to the current date in whatever
    > >>>> calendar system.
    > >>>>
    > >>>> And 2.x+1.y-rcZ+1 immediately following 2.x.y-rcZ really hurts my eyes
    > >>>
    > >>> Hm, why would that happen?
    > >>
    > >> with the date based numbers, that was one of the things that 'could'
    > >> happen as the year changed (2008.5.0-rc4 would be followed by
    > >> 2009.1.0-rc5)

    > >
    > > Well, in that case I think it would be reasonable to cuntinue the 2008
    > > numbering so that 2009.1.0-rc5 in your example would still be 2008.5.0-rc5.
    > >
    > > That said, I kind of agree that the numbering need not be time-related. One
    > > alternative might be to release 2.9.0 instead of 2.6.29 and then continue in
    > > in such a way that each of the three numbers is always a one-digit decimal.
    > > Then, we'd have 2.9.0, 2.9.1 ... 2.9.9, 3.0.0, 3.0.1 etc.

    >
    > so how would you do the -stable releases?


    In the same way as they are done now, ie. 2.9.0.1, 2.9.0.2 etc. I don't think
    there's any problem with having 2.9.1.33 for example. ;-)

    Thanks,
    Rafael
    --
    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/

  9. Re: [RFC] Kernel version numbering scheme change

    On Sat, Oct 18, 2008 at 06:33:52PM -0400, Jan Engelhardt wrote:
    >
    > On Wed 2008-10-15 17:25:09 -0700, Grek KH wrote to Linus Torvalds:
    > >
    > >You brought this topic up a few months ago, and passed it off as
    > >something we would discuss at the kernel summit.

    >
    > On Friday 2008-10-17 17:44, Greg KH wrote:
    > >
    > >Seriously, am I the only one that is getting annoyed by our version
    > >numbers? If so, I can live with it, but I got the feeling that I wasn't
    > >alone here.

    >
    >
    > If there is a real discontent about the version number
    > it would have already been changed.
    > Given that nothing happened, it seems it is tolerated.


    Huh? I'm showing discontent here. Is that not "real"?

    thanks,

    greg k-h
    --
    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/

  10. Re: [RFC] Kernel version numbering scheme change


    On Sunday 2008-10-19 14:33, Greg KH wrote:
    >>
    >> If there is a real discontent about the version
    >> number it would have already been changed.

    ^{on Linus's side}
    >> Given that nothing happened, it seems it is tolerated.

    >
    >Huh? I'm showing discontent here. Is that not "real"?

    --
    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/

  11. Re: [RFC] Kernel version numbering scheme change

    On Sun, 19 Oct 2008, Jan Engelhardt wrote:

    > On Sunday 2008-10-19 14:33, Greg KH wrote:
    >>>
    >>> If there is a real discontent about the version
    >>> number it would have already been changed.

    > ^{on Linus's side}
    >>> Given that nothing happened, it seems it is tolerated.


    he is the one who raised the subject, so there is discontent. Linus asked
    the question of what to move to.

    David Lang
    --
    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/

  12. Re: [RFC] Kernel version numbering scheme change

    On Oct 18, 2008, "H. Peter Anvin" wrote:

    > Greg KH wrote:
    >> What is the "problem" of predicting future releases? What relies on the
    >> actual number being "correct" some random time in the future?


    > We already have the 2.6.28-rc series; and we are already talking about
    > 2.6.29 features.


    Just do like car manufacturers. When it's 2008, you can already shop
    around their 2009 models. Linux could do the same. We could right
    now decide that 2.6.29 is going to be 2009.1 (or 9.1, or 2.9.1,
    whatever), and then, even if it's still 2008 when it goes out, so
    what?

    (The 2.6.28 cycle has already started, so it's probably easier to just
    leave it alone)

    > We *really* don't want 2008.3-rc4 to be followed by 2009.1-rc5.
    > That is the kind of stuff that make script makers want to strangle
    > developers alive with their own intestines.


    +1

    Not that I care one way or the other. It's just that I don't see how
    your response bears any relationship with the point Greg made. It's
    just a distraction. We're talking about how to label releases, not
    about guessing the release date of a kernel months ahead. One you
    label it, it stays that way.

    --
    Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
    Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
    FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/
    Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
    --
    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/

  13. Re: [RFC] Kernel version numbering scheme change

    On Thursday 16 October 2008 08:35, Theodore Tso wrote:
    > Let's just leave things the way they are.


    Or drop the useless fourth number and resume incrementing the minor
    number if not the major.

    Or just leave things the way they are, indeed. I see Linus has
    managed a prodigious silence on the troll, err, subject and with luck
    it will stay that way.

    Regards,

    Daniel
    --
    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/

  14. Re: [RFC] Kernel version numbering scheme change

    Alexandre Oliva wrote:
    >
    >> We *really* don't want 2008.3-rc4 to be followed by 2009.1-rc5.
    >> That is the kind of stuff that make script makers want to strangle
    >> developers alive with their own intestines.

    >
    > +1
    >
    > Not that I care one way or the other. It's just that I don't see how
    > your response bears any relationship with the point Greg made. It's
    > just a distraction. We're talking about how to label releases, not
    > about guessing the release date of a kernel months ahead. One you
    > label it, it stays that way.
    >


    Uhm, so what happens when a release starts with an -rc stage intended
    for 2008 release, and then comes out in 2009? You either have to leave
    it at 2008, which would be confusing (I think this is what M$ did in at
    least one case), or you have to have an in-release-cycle change.

    Plus, of course, it makes it hard to talk about future releases.

    -hpa
    --
    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/

  15. Re: [RFC] Kernel version numbering scheme change

    On Oct 20, 2008, "H. Peter Anvin" wrote:

    > Uhm, so what happens when a release starts with an -rc stage intended
    > for 2008 release, and then comes out in 2009?


    I see at least two possibilities:

    - it stays 2008, as originally intended.

    - it's labeled 2009 since the beginning of the release cycle

    If it gets released in a year other than originally planned, it's no
    more confusing that buying a 2009-series car in 2008, or Fiscal Years
    vs Calendar Years.

    Personally, I'd rather go with the second option than the first, if
    nothing else because people seem to like better next year's stuff than
    last year's stuff. But it's not like it matters much. The point
    (AFAICT) is to give some rough guidance of the time-frame of the
    release, not something like $(date +%s) of the beginning or end of the
    release cycle.

    Major might as well be defined as Year+/-1 - Constant, monotonically
    increasing. This should work and make sense as long as no release
    cycle takes longer than say a year or two.

    > Plus, of course, it makes it hard to talk about future releases.


    Not that it makes a lot of sense to talk about future releases other
    than the next two or so, but we could right now agree to use the
    following replacement table. Does your roadmap cover longer than
    that? Did I get the release year approximations wrong?

    2.6.28 doesn't change
    2.6.29 <-> 2009.1
    2.6.30 <-> 2009.2
    2.6.31 <-> 2009.3
    2.6.32 <-> 2010.1
    2.6.33 <-> 2010.2
    2.6.34 <-> 2010.3
    2.6.35 <-> 2010.4

    --
    Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
    Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
    FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/
    Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
    --
    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/

  16. Re: [RFC] Kernel version numbering scheme change

    Alexandre Oliva wrote:
    > Not that I care one way or the other. It's just that I don't see how
    > your response bears any relationship with the point Greg made. It's
    > just a distraction. We're talking about how to label releases, not
    > about guessing the release date of a kernel months ahead. One you
    > label it, it stays that way.


    Greg,

    I do agree with you that kernel numbering is becoming increasingly
    cumbersome now the numbers are becoming larger, and a spreadsheet is
    becoming a handy tool for tracking all this release information.

    I'm honestly not sold on any of the naming schemes proposed thusfar, but
    since I can't come up with a magic solution, I'll shut up about that!

    What I'd love to see any changes integrate would be a simple way to spot
    -stable releases in the version number (ie: 2.6.16, 2.6.27, those
    maintained for a "long" time and hopefully by 2.6.16.50+ quite 'bug
    free') versus the rest of releases sent out on a more regular basis.

    I'll immediately concede this is probably of minimal benefit to
    distribution maintainers who're actively following LKML and development
    in general, but there is a big community of folks out there using
    vanilla kernel.org sources for their own needs who, like me, probably
    find it difficult/frustrating to pick a kernel version these days.

    Does anyone have a suggestion how that could be accomplished?

    Alex
    --
    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/

  17. Re: [RFC] Kernel version numbering scheme change

    On Sat, Oct 18, 2008 at 10:45:05AM +0200, Willy Tarreau wrote:
    > On Fri, Oct 17, 2008 at 02:44:09PM -0700, Greg KH wrote:
    > > On Fri, Oct 17, 2008 at 08:47:23PM +0100, Alan Cox wrote:
    > > > > And that's my point here, do we want to change the current numbering
    > > > > scheme as people have expressed annoyances of the current one.
    > > >
    > > > But any new scheme will be just as annoying to someone and it messes up
    > > > existing documentation, understanding and risks breaking third party
    > > > tools.
    > > >
    > > > Is it really worth the hassle, plus we'll have to change again if we use
    > > > date/times because once we are shipping Linux out to Alpha Centauri with
    > > > colonists there will be serious problems trying to compute the effect of
    > > > tau on release numbering ...

    > >
    > > Sure, but by then, the 2.6.521 release will be out and we could fix it
    > > up by finally going to 3.0
    > >
    > > Seriously, am I the only one that is getting annoyed by our version
    > > numbers? If so, I can live with it, but I got the feeling that I wasn't
    > > alone here.

    >
    > No you're not. I am too. Maybe we're both more annoyed than majority
    > because we're mostly dealing with 4-numbers versions.
    >
    > I remember having recently suggested someone to test 2.6.37, doing a
    > confusion between 2.4.37 and 2.6.27. I have already tagged kernels
    > with wrong versions, having to fix by hand afterwards. It's really
    > cumbersome some times.


    Yeah, I'm not the only one that has done that then

    And yes, it is a pain to fix up.

    > IMHO, having a small number of small digits is the way to go. Using
    > 1 or 2 digits for the major and 1 for the minor is fine. After 3.9, you
    > go to version 4.0. Anyway, there are so many changes between versions
    > these days that any new versions could justify a major change (eg:
    > check the size of the 2.6.27 patch).
    >
    > With versions from 1.1 to 9.9, you can go as high as 88 versions,
    > which is about 22 years of development at current pace. After that,
    > we can simply turn to 10.0 and not break anything.
    >
    > It's also easier for users. Check how many non-kernel techies around you
    > know all 3 digits of the version they use. It's easier to remember 4.3
    > than it is to remember 2.6.27.


    I agree that would be nicer, and easier for everyone.

    thanks,

    greg k-h
    --
    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/

  18. Re: [RFC] Kernel version numbering scheme change

    On Mon, Oct 20, 2008 at 07:55:29PM +0100, Alex Howells wrote:
    > Alexandre Oliva wrote:
    >> Not that I care one way or the other. It's just that I don't see how
    >> your response bears any relationship with the point Greg made. It's
    >> just a distraction. We're talking about how to label releases, not
    >> about guessing the release date of a kernel months ahead. One you
    >> label it, it stays that way.

    >
    > Greg,
    >
    > I do agree with you that kernel numbering is becoming increasingly
    > cumbersome now the numbers are becoming larger, and a spreadsheet is
    > becoming a handy tool for tracking all this release information.
    >
    > I'm honestly not sold on any of the naming schemes proposed thusfar, but
    > since I can't come up with a magic solution, I'll shut up about that!
    >
    > What I'd love to see any changes integrate would be a simple way to spot
    > -stable releases in the version number (ie: 2.6.16, 2.6.27, those
    > maintained for a "long" time and hopefully by 2.6.16.50+ quite 'bug free')
    > versus the rest of releases sent out on a more regular basis.


    What do you mean? The .y marking of releases right now doesn't show you
    this?

    The "longevity" of a release series has no real correlation to it's "bug
    free"ness of it in any strict sense of the word. Just look at the
    percentage of fixes in any normal release for "bugs" to get a concrete
    feel for that (hint, it's in the thousands).

    > I'll immediately concede this is probably of minimal benefit to
    > distribution maintainers who're actively following LKML and development in
    > general, but there is a big community of folks out there using vanilla
    > kernel.org sources for their own needs who, like me, probably find it
    > difficult/frustrating to pick a kernel version these days.


    What is frustrating about it right now? It is _strongly_ recommended
    that if you are following the kernel.org tree, for you to rely on the
    -stable releases. It is best if you can upgrade to the latest branch of
    the stable releases when they come out, moving to the latest major
    release when possible, as you usually only have a month or so when they
    start up before the previous branch's stable tree stops being
    maintained.

    Some times I think I need to put up a big .SVG drawing of all of the
    releases, showing which ones are currently being maintained, and which
    ones aren't just to make it easier. I wonder if firefox could show it
    properly, would that help out?

    thanks,

    greg k-h
    --
    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/

  19. Re: [RFC] Kernel version numbering scheme change

    On Mon, Oct 20, 2008 at 01:30:33PM -0700, Greg KH wrote:
    > > IMHO, having a small number of small digits is the way to go. Using
    > > 1 or 2 digits for the major and 1 for the minor is fine. After 3.9, you
    > > go to version 4.0. Anyway, there are so many changes between versions
    > > these days that any new versions could justify a major change (eg:
    > > check the size of the 2.6.27 patch).
    > >
    > > With versions from 1.1 to 9.9, you can go as high as 88 versions,
    > > which is about 22 years of development at current pace. After that,
    > > we can simply turn to 10.0 and not break anything.
    > >
    > > It's also easier for users. Check how many non-kernel techies around you
    > > know all 3 digits of the version they use. It's easier to remember 4.3
    > > than it is to remember 2.6.27.

    >
    > I agree that would be nicer, and easier for everyone.


    It's true it would be easier for tracking down and remembering the
    version number, but on the other hand, the good thing about this
    version number system is that we now 2.6.xx is a rather stable and
    complete kernel tree and when we move to 2.7, we know it'll be the start
    for the 2.8 kernel series.

    Just like the migration from 2.4 to 2.5.

    Also, changing now the version numbering would be troublesome as well.
    Most of the users/developers who tracks linux-2.6.git are used to
    have 3 levels of version number.

    Still, it's nice to start thinking about it now since we're getting
    closer to last sublevel of 2.4 series (i think it was 2.4.37 ??) and try
    to find a new scheme for version numbering before thinking about 2.7 (or
    3.0 ??) series.

    --
    balbi
    --
    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/

  20. Re: [RFC] Kernel version numbering scheme change

    On Mon, Oct 20, 2008 at 11:54:00PM +0300, Felipe Balbi wrote:
    > On Mon, Oct 20, 2008 at 01:30:33PM -0700, Greg KH wrote:
    > > > IMHO, having a small number of small digits is the way to go. Using
    > > > 1 or 2 digits for the major and 1 for the minor is fine. After 3.9, you
    > > > go to version 4.0. Anyway, there are so many changes between versions
    > > > these days that any new versions could justify a major change (eg:
    > > > check the size of the 2.6.27 patch).
    > > >
    > > > With versions from 1.1 to 9.9, you can go as high as 88 versions,
    > > > which is about 22 years of development at current pace. After that,
    > > > we can simply turn to 10.0 and not break anything.
    > > >
    > > > It's also easier for users. Check how many non-kernel techies around you
    > > > know all 3 digits of the version they use. It's easier to remember 4.3
    > > > than it is to remember 2.6.27.

    > >
    > > I agree that would be nicer, and easier for everyone.

    >
    > It's true it would be easier for tracking down and remembering the
    > version number, but on the other hand, the good thing about this
    > version number system is that we now 2.6.xx is a rather stable and
    > complete kernel tree and when we move to 2.7, we know it'll be the start
    > for the 2.8 kernel series.


    Um, did you not get the memo 3 years ago saying we are changing our
    development model and there will not be a 2.7 development series?

    Damm, I thought I had printed it out and placed it on everyone's chairs.
    Those pesky cleaners must have picked it up and recycled it, sorry about
    that...

    > Just like the migration from 2.4 to 2.5.


    Please don't bring up the dark ages again, many of us went through
    things back then that have taken a lot of counseling to be able to get
    over.

    thanks,

    greg k-h
    --
    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/

+ Reply to Thread
Page 5 of 6 FirstFirst ... 3 4 5 6 LastLast