[RFC] Kernel version numbering scheme change - Kernel

This is a discussion on [RFC] Kernel version numbering scheme change - Kernel ; Hi, You brought this topic up a few months ago, and passed it off as something we would discuss at the kernel summit. But that never happened, so I figured I'd bring it up again here. So, as someone who ...

+ Reply to Thread
Page 1 of 6 1 2 3 ... LastLast
Results 1 to 20 of 111

Thread: [RFC] Kernel version numbering scheme change

  1. [RFC] Kernel version numbering scheme change

    Hi,

    You brought this topic up a few months ago, and passed it off as
    something we would discuss at the kernel summit. But that never
    happened, so I figured I'd bring it up again here.

    So, as someone who constantly is dealing with kernel version numbers all
    the time with the -stable trees, our current numbering scheme is a pain
    a times. How about this proposal instead?

    We number the kernel based on the year, and the numbers of releases we
    have done this year:
    YEAR.NUMBER.MINOR_RELEASE

    For example, the first release in 2009 would be called:
    2009.0.0
    The second:
    2009.1.0

    If we want to be a bit more "non-zero-counting" friendly: we can start
    at "1" for the number:
    2009.1.0 for the first release
    2009.2.0 for the second.

    Then the stable releases can increment the minor number:
    2009.1.1 for the first stable release
    2009.1.2 for the second.
    and so on.

    Benefits of this is it more accuratly represents to people just how old
    the kernel they are currently running is (2.6.9 would be have been
    2004.9.0 on this naming scheme.)

    Yes, we can handle the major/minor macros in the kernel to provide a
    compatible number so that automated scripts will not break, that's not a
    big deal.

    Any thoughts?

    Let the bike-shedding begin!

    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/

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

    Greg KH wrote:
    >
    > Yes, we can handle the major/minor macros in the kernel to provide a
    > compatible number so that automated scripts will not break, that's not a
    > big deal.
    >
    > Any thoughts?
    >
    > Let the bike-shedding begin!
    >


    Personally I find that having a simple counter is kind of nice, simply
    because one can talk about 27, 28, 29, ... and actually be able to rely
    on it being stable.

    The 2.6 prefix has clearly outlived its utility. The easiest way to
    deal with that is of course to simply drop it, but perhaps the best
    thing to do would be to bump the major number to 3, and start out with
    3.0 instead of 2.6.28, 3.1 for 2.6.29 and so on. This has the advantage
    that we still retain the major number for "huge changes".

    On the other hand, a number of projects have gone to simple counters for
    version numbers, without a leading major. Just having *one* number (or
    two for point releases) compensates to a large degree for the numbers
    being large. Given that, we could just make it version 3 instead of
    2.6.28, 4 instead of 2.6.29 and so on.

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

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

    On Wednesday 15 October 2008 09:03:37 pm H. Peter Anvin wrote:
    > Greg KH wrote:
    > > Yes, we can handle the major/minor macros in the kernel to provide a
    > > compatible number so that automated scripts will not break, that's not a
    > > big deal.
    > >

    > Personally I find that having a simple counter is kind of nice, simply
    > because one can talk about 27, 28, 29, ... and actually be able to rely
    > on it being stable.


    How about 2008.27.0, 2008.27.1, 2008.28.0, ...
    David
    --
    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 Wed, Oct 15, 2008 at 06:03:37PM -0700, H. Peter Anvin wrote:
    > Greg KH wrote:
    >> Yes, we can handle the major/minor macros in the kernel to provide a
    >> compatible number so that automated scripts will not break, that's not a
    >> big deal.
    >> Any thoughts?
    >> Let the bike-shedding begin!

    >
    > Personally I find that having a simple counter is kind of nice, simply
    > because one can talk about 27, 28, 29, ... and actually be able to rely on
    > it being stable.


    I would love to do that, start with 28.0 and go from there.

    It's just a number, might as well just treat it as such

    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/

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

    On Thu, 16 Oct 2008, Thorsten Leemhuis wrote:

    > On 16.10.2008 02:25, Greg KH wrote:
    >> You brought this topic up a few months ago, and passed it off as
    >> something we would discuss at the kernel summit. But that never
    >> happened, so I figured I'd bring it up again here.
    >>
    >> So, as someone who constantly is dealing with kernel version numbers all
    >> the time with the -stable trees, our current numbering scheme is a pain
    >> a times. How about this proposal instead?
    >>
    >> We number the kernel based on the year, and the numbers of releases we
    >> have done this year:
    >> YEAR.NUMBER.MINOR_RELEASE
    >>
    >> For example, the first release in 2009 would be called:
    >> 2009.0.0
    >> The second:
    >> 2009.1.0
    >> [...]

    >
    > That afaics has one minor downside: You don't know in advance how the next
    > kernel is going to be called. Example: the kernel that is currently developed
    > could become 2008.4 (the fifth kernel in 2008) if this development cycle in
    > the end is one of the quicker ones and gets finished this year. But if
    > everything is a bit slower then it might become 2009.0 (the first one in
    > 2009).
    >
    > 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

    either based on when the merge window opens, or when it's expected to be
    released (and accept that you may have a 2008.3 released in early 2009, or
    a 2009.1 released in december 2008)

    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 16.10.2008 02:25, Greg KH wrote:
    > You brought this topic up a few months ago, and passed it off as
    > something we would discuss at the kernel summit. But that never
    > happened, so I figured I'd bring it up again here.
    >
    > So, as someone who constantly is dealing with kernel version numbers all
    > the time with the -stable trees, our current numbering scheme is a pain
    > a times. How about this proposal instead?
    >
    > We number the kernel based on the year, and the numbers of releases we
    > have done this year:
    > YEAR.NUMBER.MINOR_RELEASE
    >
    > For example, the first release in 2009 would be called:
    > 2009.0.0
    > The second:
    > 2009.1.0
    > [...]


    That afaics has one minor downside: You don't know in advance how the
    next kernel is going to be called. Example: the kernel that is currently
    developed could become 2008.4 (the fifth kernel in 2008) if this
    development cycle in the end is one of the quicker ones and gets
    finished this year. But if everything is a bit slower then it might
    become 2009.0 (the first one in 2009).

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

    > [...] Let the bike-shedding begin!


    Please paint a tux on top of the roof.

    CU
    thl
    --
    Thorsten Leemhuis
    c't- Magazin für Computertechnik web http://www.heise.de/ct/
    Heise Zeitschriften Verlag GmbH&Co.KG phone +49 (0)511 5352 300
    Helstorfer Str. 7 icq 140593172
    D-30625 Hannover, Germany jabber thl_at_work@jabber.ccc.de

    /* Heise Zeitschriften Verlag GmbH & Co. KG, Registergericht:
    Amtsgericht Hannover HRA 26709; Persönlich haftende Gesellschafterin:
    Heise Zeitschriften Verlag Geschäftsführung GmbH, Registergericht:
    Amtsgericht Hannover, HRB 60405 Geschäftsführer: Ansgar Heise,
    Steven P. Steinkraus, Dr. Alfons Schräder */
    --
    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

    Greg KH kroah.com> writes:

    >
    > Hi,
    >
    > You brought this topic up a few months ago, and passed it off as
    > something we would discuss at the kernel summit. But that never
    > happened, so I figured I'd bring it up again here.
    >
    > So, as someone who constantly is dealing with kernel version numbers all
    > the time with the -stable trees, our current numbering scheme is a pain
    > a times. How about this proposal instead?
    >
    > We number the kernel based on the year, and the numbers of releases we
    > have done this year:
    > YEAR.NUMBER.MINOR_RELEASE
    >


    I strongly disagree about the full year indication in front

    and bring up my older idea of

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

    s - series, as it is now (freedom to Linus to declare a whole 'new generation'

    if he wanted )

    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.

    It is:
    - most similar to the scheme used so far,
    - informative : the ww and tt numbers are the week numbers of when the actual

    release HAPPENED, not when it is predicted.

    - easy to put some automation into it (git release HEAD now ) could branch the

    current and rename it accordingly (not that I know how to do it, just

    imagination)

    - (mod) in case there are more than one release in a week, letters could be

    used (e.g. 2.08.44[a..z]) in as many count as needed (2.08.45deadbeef.50sodead
    )(or put the git commit indication there ?)

    - in case the stable releases go forth into next year or over, the stable team

    puts additional .yy.ww instead of their own .tt (like 2.08.45.09.05) (yes I know

    it is long)

    - the -rc releases go as usual beginning with latest mainline release

    (2.08.45-rcX, X being a number as it is now)

    - dubbing behavior of silicon manufacturers who print the actual week number of

    production onto their chips - imagine looking at a chip and quick glancing at

    the kernel version number and _knowing_ it should be OK


    My £0.02
    >
    > Any thoughts?
    >
    > Let the bike-shedding begin!
    >
    > thanks,
    >
    > greg k-h
    >


    Lukasz


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

    el es wrote:
    >
    > the scheme to be s.yy.ww.tt, that is :
    >
    > s - series, as it is now (freedom to Linus to declare a whole 'new generation'
    >
    > if he wanted )
    >
    > 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.
    >
    > It is:
    > - most similar to the scheme used so far,
    > - informative : the ww and tt numbers are the week numbers of when the actual
    >
    > release HAPPENED, not when it is predicted.
    >


    Which really sucks for dealing with 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/

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

    On Wed, Oct 15, 2008 at 05:25:09PM -0700, Greg KH wrote:
    >
    > Benefits of this is it more accuratly represents to people just how old
    > the kernel they are currently running is (2.6.9 would be have been
    > 2004.9.0 on this naming scheme.)


    That would be a nice advantage, especially in embedded land where
    industry people frequently use ancient kernels. OTOH, those people also
    still use Windows 2000 without realizing what the "2000" implies.

    Hans

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

    H. Peter Anvin zytor.com> writes:

    >
    > el es wrote:

    [snip]
    > > - informative : the ww and tt numbers are the week numbers of when the actual
    > >
    > > release HAPPENED, not when it is predicted.
    > >

    >
    > Which really sucks for dealing with future releases.
    >


    Why ?
    What do you mean by 'future releases' ?
    Can you predict exactly when the next release will happen ? The current practice
    of -rcX shows clearly you cannot.

    Moreover, with my idea you could easily say, which stable release is still
    supported (and how old its mainline really was) up to the week, which IMHO is
    granular enough.
    Also you could for sure say, that e.g. a device/software that hit market in say
    December this year, will be compatible with e.g. 2.09.XX+ - look at users POV.

    Current scheme is great, established and understandable, but sucks at this
    point : for any product, be it hardware or software, you need to print both its
    date of creation AND the minimum kernel that supports it. With my idea, it is
    only the date you need.

    > -hpa
    >


    Lukasz


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

    el es yahoo.co.uk> writes:

    >
    > H. Peter Anvin zytor.com> writes:
    >
    > >
    > > el es wrote:

    > [snip]
    > > > - informative : the ww and tt numbers are the week numbers of when the
    > > > actual release HAPPENED, not when it is predicted.


    > > Which really sucks for dealing with future releases.
    > >

    >
    > Why ?
    > What do you mean by 'future releases' ?


    Oh, I just read your suggestion to move on with 3, 4 and so on. To keep it
    simple.

    How about adopting your scheme (simple counter) with mine (yy.ww.tt) ?

    Speaking on my own, I think that some indication of WHEN the release actually
    happened, encoded in the version number, IS desirable. I'm not a developer (my
    field is far, far away) but personally I find the suggestions to put full year
    figure in front, grossly disturbing everything we accustomed to

    OR.
    If in my idea, we drop the .tt bit, hence, we declare, that the stable team just
    continues the work on the released version, like

    - 2.08.41 is the currently released 2.6.27,
    - developers continue on 2.08.41-rcX, which gets promoted to 3.yy.ww when
    released and so on,
    - meanwhile the stable team releases 2.08.[42..52], 2.09.[01..52] and so on.

    Being an indication of continuity.
    As well as a revolution too
    > >

    >
    > Lukasz
    >
    >





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

    Please don't use time indications inside kernel versions, it just gets confusing
    (even more so if you use yy mm dd).


    On Thu, 16 Oct 2008 10:05:32 +0000 (UTC)
    el es wrote:

    > el es yahoo.co.uk> writes:
    >
    > >
    > > H. Peter Anvin zytor.com> writes:
    > >
    > > >
    > > > el es wrote:

    > > [snip]
    > > > > - informative : the ww and tt numbers are the week numbers of when the
    > > > > actual release HAPPENED, not when it is predicted.

    >
    > > > Which really sucks for dealing with future releases.
    > > >

    > >
    > > Why ?
    > > What do you mean by 'future releases' ?

    >
    > Oh, I just read your suggestion to move on with 3, 4 and so on. To keep it
    > simple.
    >
    > How about adopting your scheme (simple counter) with mine (yy.ww.tt) ?
    >
    > Speaking on my own, I think that some indication of WHEN the release actually
    > happened, encoded in the version number, IS desirable. I'm not a developer (my
    > field is far, far away) but personally I find the suggestions to put fullyear
    > figure in front, grossly disturbing everything we accustomed to
    >
    > OR.
    > If in my idea, we drop the .tt bit, hence, we declare, that the stable team just
    > continues the work on the released version, like
    >
    > - 2.08.41 is the currently released 2.6.27,
    > - developers continue on 2.08.41-rcX, which gets promoted to 3.yy.ww when
    > released and so on,
    > - meanwhile the stable team releases 2.08.[42..52], 2.09.[01..52] and so on.
    >
    > Being an indication of continuity.
    > As well as a revolution too
    > > >

    > >
    > > Lukasz
    > >
    > >

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



    --
    Kristoffer Ericson

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEARECAAYFAkj3FBIACgkQPQls10ERAGdpGgCgs+8JuA5TwS dxRONJyGdhgfMo
    1VoAnjw5f06ag90ScdbU9x04pDkVv83n
    =5KgW
    -----END PGP SIGNATURE-----


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

    On Wed, Oct 15, 2008 at 05:25:09PM -0700, Greg KH wrote:
    > Hi,


    Hi Greg,

    >...
    > Yes, we can handle the major/minor macros in the kernel to provide a
    > compatible number so that automated scripts will not break, that's not a
    > big deal.
    >
    > Any thoughts?
    >...


    how much of userspace breaks when we suddenly "just for fun" change the
    version numbering scheme in a very radical way?

    I'm not thinking of scripts for building the kernel.

    I'm thinking of the fact that starting with glibc different pieces of
    userspace software interpret the kernel version number they get from
    various sources like e.g. , "uname -r" or an ioctl.

    As a random example, the "config" script of OpenSSL 0.9.8g contains the
    following:

    <-- snip -->

    ....
    RELEASE=`(uname -r) 2>/dev/null` || RELEASE="unknown"
    ....
    case "${SYSTEM}:${RELEASE}:${VERSION}:${MACHINE}" in
    ....
    Linux:[2-9].*)
    echo "${MACHINE}-whatever-linux2"; exit 0
    ;;

    Linux:1.*)
    echo "${MACHINE}-whatever-linux1"; exit 0
    ;;
    ....

    <-- snip -->


    Change the version number of the kernel in the way you suggest, and
    trying to build it will fail with:

    <-- snip -->

    $ ./config
    Operating system: x86_64-whatever-Linux
    This system (Linux) is not supported. See file INSTALL for details.
    $

    <-- snip -->


    If a distribution will try to autobuild an urgent OpenSSL security
    update for their stable release in a chroot on a machine running
    kernel 2009.2.3 they will surely love you for being responsible
    for this...


    > thanks,
    >
    > greg k-h


    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

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

    * Greg KH wrote:

    > So, as someone who constantly is dealing with kernel version
    > numbers all the time with the -stable trees, our current numbering
    > scheme is a pain a times. How about this proposal instead?


    Why not just keep it? It has worked so far, and from a strictly
    end-user point of view I cannot see any advantages at all with a new
    scheme. The ideas mentioned so far don't cut it either.

    Just my heretic 2 cents,
    S.

    PS: Nice timing, thunderstorm approaching.

    --
    In Russia, President kills Financial Crisis

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEARECAAYFAkj3TwsACgkQLMyTO8Kj/uQ86wCfVPZHTqFe3RHuvoaixCEE4E4g
    ffkAoIdk2NfFnC1J/FnHN8UCjTktLm4x
    =GKLb
    -----END PGP SIGNATURE-----


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

    On Wed, 15 Oct 2008, Greg KH wrote:
    > You brought this topic up a few months ago, and passed it off as
    > something we would discuss at the kernel summit. But that never
    > happened, so I figured I'd bring it up again here.
    >
    > So, as someone who constantly is dealing with kernel version numbers all
    > the time with the -stable trees, our current numbering scheme is a pain
    > a times. How about this proposal instead?


    > Any thoughts?
    >
    > Let the bike-shedding begin!


    What about just using the git SHA1?

    Advantages:
    - We're all getting older. Training our memory to remember SHA1 IDs is
    actually good for us!
    - Perhaps Google will finally start tracking git commits, so I can
    feed them a git commit ID mentioned in a random email and find the
    actual commit, without having to know to which repository it
    belongs?

    Gr{oetje,eeting}s,

    Geert

    --
    Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

    In personal conversations with technical people, I call myself a hacker. But
    when I'm talking to journalists I just say "programmer" or something like that.
    -- Linus Torvalds
    --
    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

    On Thu, Oct 16, 2008 at 03:49:43PM +0300, Adrian Bunk wrote:
    > On Wed, Oct 15, 2008 at 05:25:09PM -0700, Greg KH wrote:
    > > Hi,

    >
    > Hi Greg,
    >
    > >...
    > > Yes, we can handle the major/minor macros in the kernel to provide a
    > > compatible number so that automated scripts will not break, that's not a
    > > big deal.
    > >
    > > Any thoughts?
    > >...

    >
    > how much of userspace breaks when we suddenly "just for fun" change the
    > version numbering scheme in a very radical way?
    >
    > I'm not thinking of scripts for building the kernel.
    >
    > I'm thinking of the fact that starting with glibc different pieces of
    > userspace software interpret the kernel version number they get from
    > various sources like e.g. , "uname -r" or an ioctl.
    >
    > As a random example, the "config" script of OpenSSL 0.9.8g contains the
    > following:
    >
    > <-- snip -->
    >
    > ...
    > RELEASE=`(uname -r) 2>/dev/null` || RELEASE="unknown"
    > ...
    > case "${SYSTEM}:${RELEASE}:${VERSION}:${MACHINE}" in
    > ...
    > Linux:[2-9].*)
    > echo "${MACHINE}-whatever-linux2"; exit 0
    > ;;
    >
    > Linux:1.*)
    > echo "${MACHINE}-whatever-linux1"; exit 0
    > ;;
    > ...
    >
    > <-- snip -->
    >
    >
    > Change the version number of the kernel in the way you suggest, and
    > trying to build it will fail with:
    >
    > <-- snip -->
    >
    > $ ./config
    > Operating system: x86_64-whatever-Linux
    > This system (Linux) is not supported. See file INSTALL for details.
    > $
    >
    > <-- snip -->
    >
    >
    > If a distribution will try to autobuild an urgent OpenSSL security
    > update for their stable release in a chroot on a machine running
    > kernel 2009.2.3 they will surely love you for being responsible
    > for this...


    Distros properly patch things and backport "urgent OpenSSL security
    updates" to older versions of packages, so they would not run into this
    problem.

    Newer releases would run into this problem, but as almost all distros
    have huge, easy to run, build systems, a change like this would show up
    immediately and be fixed in a matter of hours, with the needed fixes
    being pushed upstream to the various packages as needed.

    So I really don't think this is much of a problem.

    It's interesting that openssl doesn't just check for Linux 1.x and
    assumes that Linux 9.23.12 will work just fine with what they are doing

    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/

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

    On Thu, 16 Oct 2008, Hans J. Koch wrote:
    > On Wed, Oct 15, 2008 at 05:25:09PM -0700, Greg KH wrote:
    > > Benefits of this is it more accuratly represents to people just how old
    > > the kernel they are currently running is (2.6.9 would be have been
    > > 2004.9.0 on this naming scheme.)

    >
    > That would be a nice advantage, especially in embedded land where
    > industry people frequently use ancient kernels. OTOH, those people also
    > still use Windows 2000 without realizing what the "2000" implies.


    If you want to leapfrog Microsoft (and perhaps want to bring a tribute
    to UNIX at the same time?), just call the next version Linux 7.

    Gr{oetje,eeting}s,

    Geert

    --
    Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

    In personal conversations with technical people, I call myself a hacker. But
    when I'm talking to journalists I just say "programmer" or something like that.
    -- Linus Torvalds
    --
    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

    Greg KH (greg@kroah.com) said:
    > Distros properly patch things and backport "urgent OpenSSL security
    > updates" to older versions of packages, so they would not run into this
    > problem.
    >
    > Newer releases would run into this problem, but as almost all distros
    > have huge, easy to run, build systems, a change like this would show up
    > immediately and be fixed in a matter of hours, with the needed fixes
    > being pushed upstream to the various packages as needed.
    >
    > So I really don't think this is much of a problem.
    >
    > It's interesting that openssl doesn't just check for Linux 1.x and
    > assumes that Linux 9.23.12 will work just fine with what they are doing


    Is it really worth the effort of having any such upstream have to
    quickly patch and release, when the only benefit listed (earlier in
    this thread) was to inform people how old their kernel is?

    Bill
    --
    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 Thu, Oct 16, 2008 at 04:26:19PM +0200, markus reichelt wrote:
    > Why not just keep it? It has worked so far, and from a strictly
    > end-user point of view I cannot see any advantages at all with a new
    > scheme. The ideas mentioned so far don't cut it either.


    I'd cast a vote for keeping it as well. "2.6" is actually a great
    marker so that people know that it's highly likely the version number
    is for the Linux kernel. Contrast "I'm running 2.6.27" versus "I'm
    running 27" (huh, what does that mean?) or "I'm running the 27 kernel"
    or "I'm running Linux kernel version 27" or worse yet "I'm running
    2008-03". Something like "2.6.27" is just easier to say, and less
    prone to misunderstanding/confusion.

    Let's just leave things the way they are.

    - Ted
    --
    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 Thu, Oct 16, 2008 at 11:30:53AM -0400, Bill Nottingham wrote:
    > Greg KH (greg@kroah.com) said:
    > > Distros properly patch things and backport "urgent OpenSSL security
    > > updates" to older versions of packages, so they would not run into this
    > > problem.
    > >
    > > Newer releases would run into this problem, but as almost all distros
    > > have huge, easy to run, build systems, a change like this would show up
    > > immediately and be fixed in a matter of hours, with the needed fixes
    > > being pushed upstream to the various packages as needed.
    > >
    > > So I really don't think this is much of a problem.
    > >
    > > It's interesting that openssl doesn't just check for Linux 1.x and
    > > assumes that Linux 9.23.12 will work just fine with what they are doing

    >
    > Is it really worth the effort of having any such upstream have to
    > quickly patch and release, when the only benefit listed (earlier in
    > this thread) was to inform people how old their kernel is?


    If we switch to a consecutive numbering scheme, which doesn't show the
    "age" of the kernel, we would still have to patch such packages, so I
    don't see the big difference.

    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 1 of 6 1 2 3 ... LastLast