Kernel version : what about s.yy.ww.tt scheme ? - Kernel

This is a discussion on Kernel version : what about s.yy.ww.tt scheme ? - Kernel ; Hello, inspired by the bikeshed painting contest, I got the following idea : The scheme to be s.yy.ww.tt, that is : s - series, as it is now (freedom to Linus to bump it to 3 when BKL is removed ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: Kernel version : what about s.yy.ww.tt scheme ?

  1. Kernel version : what about s.yy.ww.tt scheme ?

    Hello,
    inspired by the bikeshed painting contest, I got the following idea :

    The scheme to be s.yy.ww.tt, that is :

    s - series, as it is now (freedom to Linus to bump it to 3 when BKL is removed
    for example )

    yy - two (in a hundred years, three) digits of the year

    Now the interesting part begins which is

    ww - the number of the week of the release. This will be between 1 and 52 (53)

    tt - the number of the week of stable release. As above.

    I see it like :

    Take a hypotetical new-scheme 2.8.30 release (roughly the current 2.6.26, didn't
    count these weeks). Linus starts to accumulate patches for 2.8.30-rcX as usual,
    and when he is ready to release, puts the release week number instead of 30 -
    let's assume it is a 2.8.40 then, more or less. By the time, the stable team
    produces 2.8.30.[32,34,36,38,40 and so on]. If the weeks leap into the next
    year, stable team puts e.g. 2.8.30.9.01 (yy.ww). This scheme would reflect the
    fast pace of development quite good, and also have the information, when the
    code in question was produced actually. I think the weekly granularity is quite
    good idea anyway.

    What do you think ?



    --
    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: Kernel version : what about s.yy.ww.tt scheme ?


    On Thursday 2008-07-17 10:51, el es wrote:

    >Hello,
    >inspired by the bikeshed painting contest, I got the following idea :
    >
    >The scheme to be s.yy.ww.tt, that is :
    >
    >s - series, as it is now (freedom to Linus to bump it to 3 when BKL is removed
    >for example )
    >yy - two (in a hundred years, three) digits of the year
    >Now the interesting part begins which is
    >ww - the number of the week of the release. This will be between 1 and 52 (53)
    >tt - the number of the week of stable release. As above.


    Interesting idea.

    >Take a hypotetical new-scheme 2.8.30 release (roughly the current
    >2.6.26, didn't count these weeks). Linus starts to accumulate
    >patches for 2.8.30-rcX as usual, and when he is ready to release,
    >puts the release week number instead of 30 - let's assume it is a
    >2.8.40 then, more or less. By the time, the stable team produces
    >2.8.30.[32,34,36,38,40 and so on]. If the weeks leap into the next
    >year, stable team puts e.g. 2.8.30.9.01 (yy.ww).


    -stable usually overlaps with master. But I don't like version
    numbers long as binutils and "2.8.30.9.01" have.

    (BTW, IMHO it needs more than just a BKL removal to warrant a jump to 3.x)
    --
    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: Kernel version : what about s.yy.ww.tt scheme ?

    Jan Engelhardt medozas.de> writes:

    > >The scheme to be s.yy.ww.tt, that is :
    > >
    > >s - series, as it is now (freedom to Linus to bump it to 3 when BKL is removed
    > >for example )
    > >yy - two (in a hundred years, three) digits of the year
    > >Now the interesting part begins which is
    > >ww - the number of the week of the release. This will be between 1 and 52 (53)
    > >tt - the number of the week of stable release. As above.

    >
    > Interesting idea.
    >


    Thanks

    > -stable usually overlaps with master. But I don't like version
    > numbers long as binutils and "2.8.30.9.01" have.


    Yes, master and stable accumulate the same patches, I know. Only master takes
    new code, whereas -stable does not.

    This however tells how long did it take to produce the -stable release out of
    Linus's release And it does not break the current habits - just abuses them a
    bit
    And tells you how long the version was around there without another -stable
    release too. Just by looking onto the version string, quick, sortable in
    meaningful way, all sorts of pluses there

    IMO, the kernel is so mature already, and the development is so fast, and the
    changes not always so fundamental, that the version in the old sense becomes
    irrelevant - it is not the 2.4->2.6 transition days any more



    Regards,
    Lukasz (btw sorry I forgot to sign myself last time



    --
    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: Kernel version : what about s.yy.ww.tt scheme ?

    On Thu, Jul 17, 2008 at 10:38 AM, el es wrote:
    > Jan Engelhardt medozas.de> writes:
    >
    >> >The scheme to be s.yy.ww.tt, that is :
    >> >
    >> >s - series, as it is now (freedom to Linus to bump it to 3 when BKL is removed
    >> >for example )
    >> >yy - two (in a hundred years, three) digits of the year
    >> >Now the interesting part begins which is
    >> >ww - the number of the week of the release. This will be between 1 and 52 (53)
    >> >tt - the number of the week of stable release. As above.

    >>
    >> Interesting idea.
    >>

    >
    > Thanks
    >
    >> -stable usually overlaps with master. But I don't like version
    >> numbers long as binutils and "2.8.30.9.01" have.

    >
    > Yes, master and stable accumulate the same patches, I know. Only master takes
    > new code, whereas -stable does not.
    >
    > This however tells how long did it take to produce the -stable release out of
    > Linus's release And it does not break the current habits - just abuses them a
    > bit
    > And tells you how long the version was around there without another -stable
    > release too. Just by looking onto the version string, quick, sortable in
    > meaningful way, all sorts of pluses there
    >
    > IMO, the kernel is so mature already, and the development is so fast, and the
    > changes not always so fundamental, that the version in the old sense becomes
    > irrelevant - it is not the 2.4->2.6 transition days any more
    >
    >
    >
    > Regards,
    > Lukasz (btw sorry I forgot to sign myself last time
    >
    >
    >
    > --
    > 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/
    >


    What about how porsch does it
    i.g. 911, 912, 913, 914

    --
    Justin P. Mattock
    --
    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: Kernel version : what about s.yy.ww.tt scheme ?

    On Thu, 17 Jul 2008, el es wrote:

    > Hello,
    > inspired by the bikeshed painting contest, I got the following idea :
    >
    > The scheme to be s.yy.ww.tt, that is :
    >
    > s - series, as it is now (freedom to Linus to bump it to 3 when BKL is removed
    > for example )
    >
    > yy - two (in a hundred years, three) digits of the year
    >
    > Now the interesting part begins which is
    >
    > ww - the number of the week of the release. This will be between 1 and 52 (53)
    >
    > tt - the number of the week of stable release. As above.
    >
    > I see it like :
    >
    > Take a hypotetical new-scheme 2.8.30 release (roughly the current 2.6.26, didn't
    > count these weeks). Linus starts to accumulate patches for 2.8.30-rcX as usual,
    > and when he is ready to release, puts the release week number instead of 30 -
    > let's assume it is a 2.8.40 then, more or less. By the time, the stable team
    > produces 2.8.30.[32,34,36,38,40 and so on]. If the weeks leap into the next
    > year, stable team puts e.g. 2.8.30.9.01 (yy.ww). This scheme would reflect the
    > fast pace of development quite good, and also have the information, when the
    > code in question was produced actually. I think the weekly granularity is quite
    > good idea anyway.
    >
    > What do you think ?


    it means that you cannot know what version of the kernel you are getting
    ready to release.

    today we can talk that we are working on 2.6.27 or 'this feature was
    accepted and will be in 2.6.27' any scheme that uses the date of the
    release means that we can't do this.

    I see this as a big problem with a fine-grained date scheme.

    if we use the year in a date-based scheme and have a near end-of-year
    release slip into the next year (2008.4 is released in Jan 2009) I don't
    see this as a major problem (the bulk of the work was done in 2008 even if
    the final release hit in 2009) under the current development cycle it's
    not like this will end up with 'version 2009.2 released in 2011' type
    emberrasements.

    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: Kernel version : what about s.yy.ww.tt scheme ?

    lang.hm> writes:


    >
    > it means that you cannot know what version of the kernel you are getting
    > ready to release.


    Yes, but when it is at large, everybody would know at a first glance, when it
    was released.

    >
    > today we can talk that we are working on 2.6.27 or 'this feature was
    > accepted and will be in 2.6.27' any scheme that uses the date of the
    > release means that we can't do this.
    >


    With current scheme you say 'it will be in next stable mainline', not telling
    any predictions when will it happen, as the stable number is only an increment,
    not bound to anything but the cycle. Which many people do not understand and/or
    do not want to. My numbering is not the date of _projected_ release, but the
    actual date (week) when the release happened. And then, the actual week when the
    stable hit large.

    > I see this as a big problem with a fine-grained date scheme.
    >
    > if we use the year in a date-based scheme and have a near end-of-year
    > release slip into the next year (2008.4 is released in Jan 2009) I don't
    > see this as a major problem (the bulk of the work was done in 2008 even if
    > the final release hit in 2009) under the current development cycle it's
    > not like this will end up with 'version 2009.2 released in 2011' type
    > emberrasements.


    Yes, my numbering addresses this issue. It is the actual date of release,
    encoded week-wise. Any development that is not expected to be 'stable' happens
    in 2.mm.ww-rcX where ww is the _last_ stable mainline, frozen. Then, at first
    glance you can tell 'Oh, your tree is 3 months older than mine, please rebase
    before I pull it' or 'Oh, I need to rebase my tree 'cause I haven't done that
    for 4 months' sort of things. Even the automated tools have it easier to tell
    you when you push a tree 'Your tree is soooo out of date. Do you really want to
    push your stale code to somebody else ?' or 'That tree you're pulling, was last
    rebased on code created last year. You sure you want it ?'. Just hypothetically.

    >
    > David Lang
    >


    el es
    [the 'what' in the topic is a thinko, but I don't want to spoil the thread]


    --
    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: Kernel version : what about s.yy.ww.tt scheme ?


    On Thursday 2008-07-17 16:27, Justin Mattock wrote:
    >
    >What about how porsch does it
    >i.g. 911, 912, 913, 914


    What about how Peugeot does it
    e.g. 306, 406, 206, 307, 407, 207, 308
    --
    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: Kernel version : what about YYYY.MM.[01].x ?

    In reading this thread I've seen folk come up with some good
    suggestions, and some bad ones. I think I can sum things up as follows:

    1) Need to clearly designate
    a) A fresh stable release
    b) Also updates to that stable release, without getting confused
    with any development releases.
    c) A fresh development release/pre-release of next stable, without
    getting confused with current stable releases.

    2) The only real objection to the status quo seems to be "the 3rd number
    is getting too big". This is highly subjective and not a good enough
    reason by itself to change the scheme.

    3) It would be nice for stable releases to encode when their initial
    version was made. This gives extra information in the version number
    without having to do a lookup. The problem with this is you don't know
    when the next stable release will actually be. This means you can't
    base your development version numbering on that, i.e. no simply
    appending -rcX to something as you don't know what the something should
    be.
    But -rcX is just one way of doing it, all we really need is for it to
    be clear if a version is part of development or part of a stable
    release.

    I therefore propose the form YYYY.MM.[sd].x

    So, 2.6.26 would have been 2008.07.s.0

    The first update to it would be 2008.07.s.1

    The development code would continue now as 2008.07.d.0 and onwards
    incrementing the last number as development progresses.

    Some might object to the user of [sd] on grounds of easy sorting. In
    which case just use 0 for stable and 1 for development. Yes, this means
    going back to the odd/even designation we had pre-2.6, but as we also
    stick to the relatively short development cycle it really doesn't
    matter. Also with the base being YYYY.MM we'll only ever use 0 and 1
    anyway.

    So, YYYY.MM.[0|1].x gives us:

    1) Clear indication of when this stable series started.
    2) Clear indication of updates to that stable version.
    3) Clear designation of the development versions started after
    that stable release.

    Note however what I said in my 2nd point. The only *real* objection to
    the current scheme is 'big numbers', and that's subjective. I only find
    it worth making a proposal due to the reasoning in my 3rd point, i.e. it
    IS a good idea to encode *when* a stable release was made in its version
    number. This not only allows someone to see how long the current
    development cycle has been going (to within +/- 4 weeks), but also
    allows a glance at all prior versions to show how quickly development
    progresses on average between stable versions.
    --
    - Athanasius = Athanasius(at)miggy.org / http://www.miggy.org/
    Finger athan(at)fysh.org for PGP key
    "And it's me who is my enemy. Me who beats me up.
    Me who makes the monsters. Me who strips my confidence." Paula Cole - ME
    --
    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: Kernel version : what about s.yy.ww.tt scheme ?

    On Fri, Jul 18, 2008 at 9:12 AM, Jan Engelhardt wrote:
    >
    > On Thursday 2008-07-17 16:27, Justin Mattock wrote:
    >>
    >>What about how porsch does it
    >>i.g. 911, 912, 913, 914

    >
    > What about how Peugeot does it
    > e.g. 306, 406, 206, 307, 407, 207, 308
    >



    Those guys are really good at rally,
    whats his name gilles pinichi(or something like that)

    --
    Justin P. Mattock
    --
    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: Kernel version : what about s.yy.ww.tt scheme ?

    On Thu, Jul 17, 2008 at 11:48:37AM +0200, Jan Engelhardt wrote:
    >
    > On Thursday 2008-07-17 10:51, el es wrote:
    >
    > >Hello,
    > >inspired by the bikeshed painting contest, I got the following idea :
    > >
    > >The scheme to be s.yy.ww.tt, that is :
    > >
    > >s - series, as it is now (freedom to Linus to bump it to 3 when BKL is removed
    > >for example )
    > >yy - two (in a hundred years, three) digits of the year
    > >Now the interesting part begins which is
    > >ww - the number of the week of the release. This will be between 1 and 52 (53)
    > >tt - the number of the week of stable release. As above.

    >
    > Interesting idea.
    >
    > >Take a hypotetical new-scheme 2.8.30 release (roughly the current
    > >2.6.26, didn't count these weeks). Linus starts to accumulate
    > >patches for 2.8.30-rcX as usual, and when he is ready to release,
    > >puts the release week number instead of 30 - let's assume it is a
    > >2.8.40 then, more or less. By the time, the stable team produces
    > >2.8.30.[32,34,36,38,40 and so on]. If the weeks leap into the next
    > >year, stable team puts e.g. 2.8.30.9.01 (yy.ww).

    >
    > -stable usually overlaps with master. But I don't like version
    > numbers long as binutils and "2.8.30.9.01" have.


    also, causes trouble when stable releases cross a year boundary, or
    when there are several ones in a week. The stable release should
    only be a counter, not a date.

    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/

  11. Re: Kernel version : what about s.yy.ww.tt scheme ?

    Willy Tarreau 1wt.eu> writes:


    >
    > also, causes trouble when stable releases cross a year boundary, or
    > when there are several ones in a week. The stable release should
    > only be a counter, not a date.
    >
    > Willy
    >
    >


    If there are more stable releases in a week, you could put a release counter
    after a dash, say : 2.08.30.40-[2...X]

    If stable continues to be used and leaps over to next year, put another .yy.ww
    section : 2.08.30.09.02

    OK I know that's long, but easy to expand if needed, just be sure to separate
    date pieces with dots and counters with dashes. Or...

    maybe use them the other way round - the current scheme uses counters separated
    by dots, so maybe the new could do ss.yy-ww-tt[[-yy]-ww][.X]] ? Like
    2.08-30-40.2 ? 2.08-30-09-02.2 ? But this seems odd, even to me

    el es

    --
    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: Kernel version : what about s.yy.ww.tt scheme ?

    On Mon, 21 Jul 2008, el es wrote:

    >>
    >> also, causes trouble when stable releases cross a year boundary, or
    >> when there are several ones in a week. The stable release should
    >> only be a counter, not a date.
    >>
    >> Willy
    >>
    >>

    >
    > If there are more stable releases in a week, you could put a release counter
    > after a dash, say : 2.08.30.40-[2...X]
    >
    > If stable continues to be used and leaps over to next year, put another .yy.ww
    > section : 2.08.30.09.02
    >
    > OK I know that's long, but easy to expand if needed, just be sure to separate
    > date pieces with dots and counters with dashes. Or...
    >
    > maybe use them the other way round - the current scheme uses counters separated
    > by dots, so maybe the new could do ss.yy-ww-tt[[-yy]-ww][.X]] ? Like
    > 2.08-30-40.2 ? 2.08-30-09-02.2 ? But this seems odd, even to me


    you are well past the point where the complexity overwelmes the
    information you are providing.

    does it really matter _exactly_ when a release was made?

    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/

  13. Re: Kernel version : what about s.yy.ww.tt scheme ?

    lang.hm> writes:


    > you are well past the point where the complexity overwelmes the
    > information you are providing.
    >
    > does it really matter _exactly_ when a release was made?
    >
    > David Lang
    >

    It might not really matter, but if you could find a reason for it to be useful,
    then why not ?

    As I wrote before, the development of the kernel is currently quite fast-paced.
    The scale of changes is not that dramatic as it was in the early days, is it ?
    Of course things get added, removed and so on. You even get lots of development
    trees tested in linux-next on a daily basis. With date-based version number, you
    can exactly position your own tree in time related to the current development.
    It is more human-readable. The version number as it is, just does not entirely
    fit the current model of development IMO - with 2 week merge window and roughly
    2 months of stabilization period, the counter becomes sort of uninformative...
    But for the releases, the week-based granularity seems to be enough - the
    current habit of having a stable by number is actually OK too, since the -stable
    team does its job. So, yes, to have a similar version number to what is used
    currently, the scheme could be s.yy.ww.[nn || -rcX], s=series (2), yy= year,
    ww=week when the tree was released, nn= stable number. What do you think ?


    --
    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: Kernel version : what about YYYY.MM.[01].x ?

    Athanasius miggy.org> writes:

    >
    > 1) Need to clearly designate
    > a) A fresh stable release
    > b) Also updates to that stable release, without getting confused
    > with any development releases.
    > c) A fresh development release/pre-release of next stable, without
    > getting confused with current stable releases.
    >
    > 2) The only real objection to the status quo seems to be "the 3rd number
    > is getting too big". This is highly subjective and not a good enough
    > reason by itself to change the scheme.
    >
    > 3) It would be nice for stable releases to encode when their initial
    > version was made. This gives extra information in the version number
    > without having to do a lookup. The problem with this is you don't know
    > when the next stable release will actually be.


    I'd agree up to this point. But you really _do_not_ want to predict 'when the
    next stable release will be' 'cause this puts pressure on people, and the
    current model works good _because_ there is little pressure... If it stops being
    fun, some really valuable people could go somewhere else... guess where ?

    > But -rcX is just one way of doing it, all we really need is for it to
    > be clear if a version is part of development or part of a stable
    > release.
    >

    No, the -rcX _is_ good and worth keeping. And the

    > I therefore propose the form YYYY.MM.[sd].x


    And this is where I disagree completely. You got rid of the traditional series
    designator ('s=2' in my scheme), you've lengthened the year part unnecessarily.
    Month is too rough grained, that's why I proposed week as a base.

    >
    > So, 2.6.26 would have been 2008.07.s.0
    >
    > The first update to it would be 2008.07.s.1
    >
    > So, YYYY.MM.[0|1].x gives us:
    >
    > 1) Clear indication of when this stable series started.
    > 2) Clear indication of updates to that stable version.
    > 3) Clear designation of the development versions started after
    > that stable release.


    It revamps the current scheme too much - I have only 'abused' it, you've got rid
    of it completely...

    >
    > This not only allows someone to see how long the current
    > development cycle has been going (to within +/- 4 weeks), but also
    > allows a glance at all prior versions to show how quickly development
    > progresses on average between stable versions.


    That's why I think week based grain is better..

    el es



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