[RFC] Kernel version numbering scheme change - Kernel

This is a discussion on [RFC] Kernel version numbering scheme change - Kernel ; On Fri, 2008-10-17 at 15:18 +0400, Alexey Dobriyan wrote: > On Fri, Oct 17, 2008 at 12:06:30PM +0200, Peter Zijlstra wrote: > > On Fri, 2008-10-17 at 11:56 +0300, Adrian Bunk wrote: > > > On Fri, Oct 17, 2008 ...

+ Reply to Thread
Page 3 of 6 FirstFirst 1 2 3 4 5 ... LastLast
Results 41 to 60 of 111

Thread: [RFC] Kernel version numbering scheme change

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

    On Fri, 2008-10-17 at 15:18 +0400, Alexey Dobriyan wrote:
    > On Fri, Oct 17, 2008 at 12:06:30PM +0200, Peter Zijlstra wrote:
    > > On Fri, 2008-10-17 at 11:56 +0300, Adrian Bunk wrote:
    > > > On Fri, Oct 17, 2008 at 12:55:44AM -0700, Greg KH wrote:
    > > > > On Fri, Oct 17, 2008 at 09:47:51AM +0300, Adrian Bunk wrote:
    > > > >...
    > > > > > Packages are built in a chroot with the correct release installed.
    > > > >
    > > > > Then why would this break if they are being built against the correct,
    > > > > older, kernel?
    > > >
    > > > How could you build userspace "against a kernel"?
    > > >
    > > > sys_*uname() returns the version of the running kernel.

    > >
    > > We have a uts namespace, you can make the thing return whatever well you
    > > please.

    >
    > Hostname, domainname, what else?


    Can't it fake the version number? - sounds like a useful feature :-)

    --
    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 Fri, Oct 17, 2008 at 01:26:27PM +0200, Peter Zijlstra wrote:
    > On Fri, 2008-10-17 at 15:18 +0400, Alexey Dobriyan wrote:
    > > On Fri, Oct 17, 2008 at 12:06:30PM +0200, Peter Zijlstra wrote:
    > > > On Fri, 2008-10-17 at 11:56 +0300, Adrian Bunk wrote:
    > > > > On Fri, Oct 17, 2008 at 12:55:44AM -0700, Greg KH wrote:
    > > > > > On Fri, Oct 17, 2008 at 09:47:51AM +0300, Adrian Bunk wrote:
    > > > > >...
    > > > > > > Packages are built in a chroot with the correct release installed.
    > > > > >
    > > > > > Then why would this break if they are being built against the correct,
    > > > > > older, kernel?
    > > > >
    > > > > How could you build userspace "against a kernel"?
    > > > >
    > > > > sys_*uname() returns the version of the running kernel.
    > > >
    > > > We have a uts namespace, you can make the thing return whatever well you
    > > > please.

    > >
    > > Hostname, domainname, what else?

    >
    > Can't it fake the version number? -


    It can, but is there a system call for this?

    > sounds like a useful feature :-)

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

    Greg KH wrote:
    > 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?


    What about:
    - rc releases: a 2009.5.0-rc4 become suddenly 2010.0.0-rc5 ?
    - a stable version in January of a kernel released in December
    still has the old year? (I hope yes, but it could confuse users.)
    - when (if) we need a big innovative (or incompatible) kernel
    change, how to mark old and new kernels?

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

    Adrian Bunk wrote:
    > On Fri, Oct 17, 2008 at 12:55:44AM -0700, Greg KH wrote:
    >> On Fri, Oct 17, 2008 at 09:47:51AM +0300, Adrian Bunk wrote:
    >> ...
    >>> Packages are built in a chroot with the correct release installed.

    >> Then why would this break if they are being built against the correct,
    >> older, kernel?

    >
    > How could you build userspace "against a kernel"?


    I imagine many embedded products regularly build (or even cross-build) a
    kernel and a matching userspace against that kernel, independent of the
    running kernel on the build machine. I know that we do it every day...

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

    Alan Cox wrote:
    >> So I proposed an alternative, YEAR.NUMBER. The year is easy to keep

    >
    > Which calendaring system ?


    Presumably the Gregorian one, rooted in the Common Era, but that's sort
    of irrelevant.

    I think it's both visually cumbersome and has the problem that it is
    harder to predict future releases. The first problem can be dealt with
    by simply subtracting 2000 from the year (Altera uses this scheme for
    their EDA tools, and I didn't realize it for quite a while because it
    looked so natural), but the second is still a problem.

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

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

    On Fri, Oct 17, 2008 at 09:40:32AM -0700, H. Peter Anvin wrote:
    > Alan Cox wrote:
    >>> So I proposed an alternative, YEAR.NUMBER. The year is easy to keep

    >> Which calendaring system ?

    >
    > Presumably the Gregorian one, rooted in the Common Era, but that's sort of
    > irrelevant.
    >
    > I think it's both visually cumbersome and has the problem that it is harder
    > to predict future releases. The first problem can be dealt with by simply
    > subtracting 2000 from the year (Altera uses this scheme for their EDA
    > tools, and I didn't realize it for quite a while because it looked so
    > natural), but the second is still a problem.


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

    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/

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

    On Fri, Oct 17, 2008 at 02:46:27PM +0200, Giacomo A. Catenazzi wrote:
    > Greg KH wrote:
    >> 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?

    >
    > What about:
    > - rc releases: a 2009.5.0-rc4 become suddenly 2010.0.0-rc5 ?


    Sure, what's the big deal?

    > - a stable version in January of a kernel released in December
    > still has the old year? (I hope yes, but it could confuse users.)


    stable versions would not modify the year.

    > - when (if) we need a big innovative (or incompatible) kernel
    > change, how to mark old and new kernels?


    Based on our current development model, this isn't an issue.

    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/

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

    On Fri, Oct 17, 2008 at 11:56:04AM +0300, Adrian Bunk wrote:
    > On Fri, Oct 17, 2008 at 12:55:44AM -0700, Greg KH wrote:
    > > On Fri, Oct 17, 2008 at 09:47:51AM +0300, Adrian Bunk wrote:
    > >...
    > > > Packages are built in a chroot with the correct release installed.

    > >
    > > Then why would this break if they are being built against the correct,
    > > older, kernel?

    >
    > How could you build userspace "against a kernel"?
    >
    > sys_*uname() returns the version of the running kernel.


    Great, then why does the build system depend on the running kernel?
    Doesn't that sound like a bug?

    > > > > and that build would be
    > > > > determining things based on the system it is built on, not what it is
    > > > > being built for?
    > > >
    > > > No.
    > > >
    > > > In the example I gave it is OpenSSL that parses the version number of
    > > > the kernel.

    > >
    > > The running kernel, with the expectation that this is the kernel it is
    > > going to be running on after it is built, right? Sounds like to ensure
    > > this is correct, you better be building it on the kernel that you are
    > > going to run it on, or its build process is broken.

    >
    > I'm not even sure whether OpenSSL actually does anything with the
    > information: The script comes from the Apache foundation and
    > claims to be "Similar to config.guess but much, much smaller."
    >
    > BTW: Apache 1.3 seems to ship and use the same script.


    Again, depending on the kernel the product is being built on, to
    determine a build-time configuration, seems quite broken if you want to
    do cross-compilation.

    Or you just do native builds, on the kernel you expect to run the
    product, and everyone is happy and there are no errors.

    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/

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

    On Fri, Oct 17, 2008 at 01:16:38AM -0700, Steven Noonan wrote:
    > I believe some of Adrian's concerns are valid. Userspace programs will
    > indeed break, largely because some depend on build-time and run-time
    > checks for the kernel version being >=2.6.0 or >=2.4.0 and so forth. I
    > suspect the best way to prove userspace breakage would be to make a
    > branch of the kernel with a new versioning scheme (8.10, 2008.10,
    > whatever) and use that as the installed kernel while building a Gentoo
    > system. I suspect you'd see massive breakage.


    That would be trivial for me to test, IFF we want to do something like
    this.

    But again, that's a technical thing, that can be solved _IFF_ we want to
    change things.

    And that's my point here, do we want to change the current numbering
    scheme as people have expressed annoyances of the current one.

    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 Fri, Oct 17, 2008 at 10:31:38AM +0100, Alan Cox wrote:
    > > So I proposed an alternative, YEAR.NUMBER. The year is easy to keep

    >
    > Which calendaring system ?


    I'm almost afraid to ask, but "which one would you prefer"?

    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/

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

    On Friday 17 October 2008, Greg KH wrote:
    > On Fri, Oct 17, 2008 at 01:16:38AM -0700, Steven Noonan wrote:
    > > I believe some of Adrian's concerns are valid. Userspace programs will
    > > indeed break, largely because some depend on build-time and run-time
    > > checks for the kernel version being >=2.6.0 or >=2.4.0 and so forth. I
    > > suspect the best way to prove userspace breakage would be to make a
    > > branch of the kernel with a new versioning scheme (8.10, 2008.10,
    > > whatever) and use that as the installed kernel while building a Gentoo
    > > system. I suspect you'd see massive breakage.

    >
    > That would be trivial for me to test, IFF we want to do something like
    > this.
    >
    > But again, that's a technical thing, that can be solved _IFF_ we want to
    > change things.
    >
    > And that's my point here, do we want to change the current numbering
    > scheme as people have expressed annoyances of the current one.


    Numbering scheme? I thought we should all be using the official
    kernel version NAME after the -final release? Was I mistaken?

    PS1 seems like somebody forgot to update it for 2.6.27...

    PS2 current numbering scheme is OK

    Thanks,
    Bart
    --
    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 Fri, 17 Oct 2008 10:41:27 -0700
    Greg KH wrote:

    > On Fri, Oct 17, 2008 at 10:31:38AM +0100, Alan Cox wrote:
    > > > So I proposed an alternative, YEAR.NUMBER. The year is easy to keep

    > >
    > > Which calendaring system ?

    >
    > I'm almost afraid to ask, but "which one would you prefer"?


    The standard one shipped and supported by util-linux for the past 15 or
    more years

    $ ddate
    Today is Setting Orange, the 71st day of Bureaucracy in the YOLD 3174

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

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

    (Ducks)

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

    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.

    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/

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

    On Fri, Oct 17, 2008 at 09:06:28PM +0200, Bartlomiej Zolnierkiewicz wrote:
    > On Friday 17 October 2008, Greg KH wrote:
    > > On Fri, Oct 17, 2008 at 01:16:38AM -0700, Steven Noonan wrote:
    > > > I believe some of Adrian's concerns are valid. Userspace programs will
    > > > indeed break, largely because some depend on build-time and run-time
    > > > checks for the kernel version being >=2.6.0 or >=2.4.0 and so forth. I
    > > > suspect the best way to prove userspace breakage would be to make a
    > > > branch of the kernel with a new versioning scheme (8.10, 2008.10,
    > > > whatever) and use that as the installed kernel while building a Gentoo
    > > > system. I suspect you'd see massive breakage.

    > >
    > > That would be trivial for me to test, IFF we want to do something like
    > > this.
    > >
    > > But again, that's a technical thing, that can be solved _IFF_ we want to
    > > change things.
    > >
    > > And that's my point here, do we want to change the current numbering
    > > scheme as people have expressed annoyances of the current one.

    >
    > Numbering scheme? I thought we should all be using the official
    > kernel version NAME after the -final release? Was I mistaken?
    >
    > PS1 seems like somebody forgot to update it for 2.6.27...


    Cool, that means I get to do it

    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/

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

    On Fri, Oct 17, 2008 at 08:45:06PM +0100, Alan Cox wrote:
    > On Fri, 17 Oct 2008 10:41:27 -0700
    > Greg KH wrote:
    >
    > > On Fri, Oct 17, 2008 at 10:31:38AM +0100, Alan Cox wrote:
    > > > > So I proposed an alternative, YEAR.NUMBER. The year is easy to keep
    > > >
    > > > Which calendaring system ?

    > >
    > > I'm almost afraid to ask, but "which one would you prefer"?

    >
    > The standard one shipped and supported by util-linux for the past 15 or
    > more years
    >
    > $ ddate
    > Today is Setting Orange, the 71st day of Bureaucracy in the YOLD 3174


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

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

    On 17.10.2008 14:44, 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.


    Personally i could live without the 4 part numbers of the stable series.

    When you bump down the third position to second, then fill the third one
    with a dummy/fixed for the "Linus" release, the way is free for stable
    releases that don't feel so stapled to the side.

    So with either .0 or .1 for the "Linus" release the next kernel could be:
    2.8.0 or 2.8.1
    (I would skip 2.7, because it is still perceived as the next development
    Version.)

    The stable releases then increment the third number and the next Linus
    release could be 2.9.x because i don't think after 2.8 any skipping of
    uneven numbers would be needed anymore.

    In Short: "Back to the roots" with a "good old" 3 part version numbers,
    with stable releases "build into the numbering scheme" instead of
    stapled to the side.




    Bis denn

    --
    Real Programmers consider "what you see is what you get" to be just as
    bad a concept in Text Editors as it is in women. No, the Real Programmer
    wants a "you asked for it, you got it" text editor -- complicated,
    cryptic, powerful, unforgiving, dangerous.

    --
    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 Friday, 17 of October 2008, 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


    Surely some scripts will start to break as soon as the third number gets
    three digits.

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


    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.

    This seems to be close enough to the current numbering so that nothing should
    really break.

    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/

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

    On Fri, 17 Oct 2008, Steven Noonan wrote:
    > I believe some of Adrian's concerns are valid. Userspace programs will
    > indeed break, largely because some depend on build-time and run-time
    > checks for the kernel version being >=2.6.0 or >=2.4.0 and so forth.


    things that do this sort of check would work just find with version 8.10.0
    or 2008.10.0

    the ones that would fail would be ones that made assumptions about the
    number (it can only have X digits in this position, I don't need to check
    the '2', only the '4' vs '6', etc). anything that does this sort of thing
    is broken already, and will fail at some point in the future, even without
    a radical numbering change.

    > I
    > suspect the best way to prove userspace breakage would be to make a
    > branch of the kernel with a new versioning scheme (8.10, 2008.10,
    > whatever) and use that as the installed kernel while building a Gentoo
    > system. I suspect you'd see massive breakage.


    I suspect that you won't see anything noticable. you don't need to make a
    branch of the kernel, just edit the kernel source to change the version.

    > I think a version numbering system change would be OK (though I
    > wouldn't very much -like- it), so long as there was a way for
    > userspace software to be able to differentiate between a kernel with
    > the old versioning system and the new versioning system.


    one nice thing about the year-based numbering (be it 8.x or 2008.x) is
    that all the numbers in the new numbering scheme are > any numbers in the
    old numbering scheme. so all you need to do is to check for > whatever
    version added the feature you need.

    > I think perhaps a better option in the long run is to start a v2.7
    > tree and figure out some Cool New Stuff(tm) to implement, keeping
    > consistency with the current versioning scheme.


    Red Herring, the Cool New Stuff is happening now, no 2.7 needed.

    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/

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

    On Sat, 18 Oct 2008, Rafael J. Wysocki wrote:

    > On Friday, 17 of October 2008, 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

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

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

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

    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/

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