Page 1 of 3 123 LastLast
Results 1 to 10 of 26

Thread: Farewell To The Linux 2.6 Kernel?

  1. #1
    Join Date
    Jan 2007
    Posts
    14,548

    Default Farewell To The Linux 2.6 Kernel?

    Phoronix: Farewell To The Linux 2.6 Kernel?

    Version 2.6 of the Linux kernel was released in late 2003 and since then the developers have stuck with the 2.6.x.y version numbering. It's been five years with the stable Linux 2.6 kernel, but a proposal has been made on the Linux kernel mailing list to change this scheme...

    http://www.phoronix.com/vr.php?view=Njc5MQ

  2. #2
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,583

    Default

    Personally I think this would be a stupid idea. To track a kernel release history would be a pain in the ass between the RC's and final. Hell even MS abandoned such stupid release monikers after Win 2k.

    ie
    2009.1.1 RC1
    2009.2.23 RC2
    .....
    2009.4.13 final

  3. #3
    Join Date
    Jan 2007
    Location
    Germany
    Posts
    2,122

    Default

    The last number is the patch version I guess. Development of the next kernel for example:

    2009.1 RC1
    2009.1 RC2
    2009.1 RC3
    2009.1.0 Final
    2009.1.1 (some fixes)
    2009.1.2 (some fixes)
    ...

  4. #4
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,583

    Default

    Quote Originally Posted by d2kx View Post
    The last number is the patch version I guess. Development of the next kernel for example:

    2009.1 RC1
    2009.1 RC2
    2009.1 RC3
    2009.1.0 Final
    2009.1.1 (some fixes)
    2009.1.2 (some fixes)
    ...
    That would be great if they could go from RC to final in a period of a month.

  5. #5

    Default

    Quote Originally Posted by deanjo View Post
    That would be great if they could go from RC to final in a period of a month.
    The aa in YYYY.aa.bb wouldn't be the month but just the release number so far that year, so the month doesn't matter at all.

  6. #6
    Join Date
    Jan 2007
    Location
    Germany
    Posts
    2,122

    Default

    They could also do a

    2008.10 RC1
    2008.10 RC2
    2008.11 RC3
    2008.11 RC4
    2008.12.0 Final

    So that the current month is the version. I personally would like it that way, but the other ways (minus Linux 3) are good, too. Linux 2.6.x doesn't mean anything anymore.

  7. #7
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,583

    Default

    Quote Originally Posted by Michael View Post
    The aa in YYYY.aa.bb wouldn't be the month but just the release number so far that year, so the month doesn't matter at all.
    OK but I really don't see the value of having a year used as a version number especially in a project that does not comply to any real set release dates or schedule.
    Last edited by deanjo; 10-17-2008 at 04:57 PM.

  8. #8
    Join Date
    Aug 2008
    Posts
    116

    Default

    Quote Originally Posted by deanjo View Post
    OK but I really don't see the value of having a year used as a version number especially in a project that does not comply to any real set release dates or schedule.
    I'm in 100% agreement with you.
    In addition to that, there's nothing intrinsically wrong with the current version naming scheme. I like the fact that it has used the same scheme for the last 4-5 years, it makes it dependable. Changing it would only lead to confusion, much like how Nvidia has messed up their versioning schemes with some cards the GeForce 9xxx series basically being re-branded 8xxx series cards, and others having a completely redesigned GPU.

    I vote for keeping the 2.6.x versioning until the end of time!
    (or until changes of significant magnitude are made to justify a 2.8.x or even 3.0 release)

  9. #9
    Join Date
    Oct 2008
    Posts
    120

    Default

    If my opinion meant anything (which it doesn't) I would vote to go with the time base numbering - but drop the stupid Millennium and century. It would have the added benefit of putting the major numbers in sync with Ubuntu, and put the current number 1 ahead of the next Windows release.

    Kubuntu 8.10, with kernel 8.27.7!

    And, only when a minor number changes should the major number change. Also, patch levels should never change the major number. That is to say - at the stroke of midnight 8.28-12 does not become 9.28.12. The next patch would still be 8.28.13... etc. 9.29.1 would be the first "new" kernel. Let the minor revision climb until there's an major re-architecture of some piece of the kernel.

    -J
    Last edited by 3vi1; 10-17-2008 at 10:34 PM.

  10. #10
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,583

    Default

    Quote Originally Posted by 3vi1 View Post
    It would have the added benefit of putting the major numbers in sync with Ubuntu,
    Linux does not revolve around ubuntu. Ubuntu's numbering scheme makes sense for them as they release on set schedules like clockwork. This does not apply to the kernel at all (or any other real opensource project). It's a lot easier to package a bunch of software together then it is to develop where unforseen events can delay a working release ranging from days to months to years.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •