Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Linux

Linus Torvalds Considering End To Linux 2.6 Series 293

Posted by Unknown Lamer from the linux-millenium-edition dept.
An anonymous reader writes "With the Linux 2.6 kernel set to begin its 40th development cycle and the Linux kernel nearing its 20th anniversary, Linus Torvalds has expressed interest today in moving away from the Linux 2.6.x kernel version. Instead he's looking to change things up by releasing the next kernel as Linux version 2.8 or 3.0."
This discussion has been archived. No new comments can be posted.

Linus Torvalds Considering End To Linux 2.6 Series More

Linus Torvalds Considering End To Linux 2.6 Series

Comments Filter:

  • How about Linux 7.0 (Score:2, Funny)

    by Anonymous Coward

    That kind of version jump will show Microsoft and Apple that Linux now has professional marketing behind it.

  • First number (Score:5, Funny)

    by SilverHatHacker ( 1381259 ) on Monday May 23, 2011 @06:04PM (#36222318)
    I remember hearing somewhere that Linus said if he ever changed the first number, it meant he had snapped and rewritten it in Python.
  • Sure this is a site for nerdy news, but this literally has no impact on anything. It's just a number.
    • There is news in this given that he has previously made statements regarding his sanity should this day ever come...

    • but this literally has no impact on anything. It's just a number.

      I have seen scripts that look for "2.6" in the result of "uname -r". Those scripts are going to be broken.

    • I assumed a this change must indicate a major break in backwards compatibility or a risky technical leap, but Linus says no:

      There's also the timing issue - since we no longer do version numbers based on features, but based on time, just saying "we're about to start the third decade" works as well as any other excuse.

  • I generally change the minor number when something important has happened, but this are still compatible. And after all of the effort that they've gone through to finally remove the Big Kernel Lock, I think they deserve a new minor version number. It really is a very different architecture inside the kernel now as compared to the start of the 2.5 series.

    • doh! it's obviously after 5 pm here. That should read 'start of the 2.6 series.' oh well.... need beer....

  • It's just a number. Is there a real roadmap as to what 2.8 or 3.0 is slated to feature?

  • Why not 20YY.x (Score:5, Interesting)

    by jisom ( 113338 ) on Monday May 23, 2011 @06:08PM (#36222366)

    Why not make it 20YY.x where x is major release that year. and YY would be current 2 digit year. they been pushing releases every 3 months about.

    • Because for that you need apparently need alphabetical $ADJECTIVE.$ANIMAL names, and that kind of went flat with Zoot-suited Zebra in the 26th release.

    • Because there is overlap in kernel development. 2.4 continued to be actively supported and developed long since 2.6 was released. If you went with release date a 2.4.36 would look like a newer kernel then a 2.6.20.

  • seems like 2.6.99 would be the last 2.6.xx kernel line before the version jump to 2.8.xx... but its his kernel and he can number em as he wants to..

  • Just to keep up with the Chromes and Winderzes and whomever.

    Plus, he should be naming releases alphabetically after a cutesy trope, like Ubuntu (Maverick Meerkat, Natty Narwhal) and Android (Gingerbread, Honeycomb, Ice Cream Sandwich) do.

    Starting with the letter I, for "I invented the fucking thing."

  • I knew it... (Score:3)

    by Lanteran ( 1883836 ) on Monday May 23, 2011 @06:15PM (#36222422) Homepage Journal
    I knew that random guy on slashdot shouldn't have recommended a change to chrome versioning numbers! Guys, linus listens!

  • Seriously -- Version numbering does mean something, and when someone says 2.8 or 3.0 to someone who knows the version numbering scheme it actually means something.

    As usual, FTWA: [wikipedia.org]

    Since 2004, after version 2.6.0 was released, the kernel developers held several discussions ... ultimately Linus Torvalds and others decided that a much shorter release cycle would be beneficial. Since then, the version has been composed of three or four numbers. The first two numbers became largely irrelevant, and the third number is the actual version of the kernel. The fourth number accounts for bug and security fixes (only) to the kernel version.

    The first use of the fourth number occurred when a grave error, which required immediate fixing, was encountered in 2.6.8's NFS code. However, there were not enough other changes to legitimize the release of a new minor revision (which would have been 2.6.9). So, 2.6.8.1 was released, with the only change being the fix of that error. With 2.6.11, this was adopted as the new official versioning policy. Later it became customary to continuously back-port major bug-fixes and security patches to released kernels and indicate that by updating the fourth number.

    Additionally, When you change the first (major) version number it usually means a significant re-write. Whereas the second version number would mean still mostly the same code-base, but with major features added/removed/rewritten.

    Take from this what you will, but to say the version numbers are arbitrary is just plain ignorant.

    • Re: (Score:2)

      by h4rr4r ( 612664 )

      When you write a kernel and have it installed on everything from phones to mainframes, you can decide what the version numbering means. Linus can decide tomorrow to call it Linux 666 and it will still be used.

      Sure you describe a fairly typical situation, but not one that is anywhere near universal.

    • Perhaps the commenters actually read the article. (Score:5, Insightful)

      by Chuck Chunder ( 21021 ) on Monday May 23, 2011 @07:21PM (#36222992) Journal

      Take from this what you will, but to say the version numbers are arbitrary is just plain ignorant.

      It seems rather strange to label others as ignorant when there is Linus saying "since we no longer do version numbers based on features, but based on time,"

    • In some senses, you can also use a version # as "ye who shall go before this version number beware of a Grue". After 36 increments of the 2.6 series, I'm sorta for the "freshness" of a 3.0 series. Just to say that "here is our dividing line, we've made all this progress, let's lock it in."

      I know, there will be a little fuss, but thinking like a 5 year plan, it's good sometimes to make some dividing lines that progress has been achieved.

  • End of the line for the distributions (Score:5, Informative)

    by greg1104 ( 461138 ) <gsmith@gregsmith.com> on Monday May 23, 2011 @06:38PM (#36222650) Homepage

    With both RHEL6 and Debian Squeeze on their own versions of 2.6.32, as well as the last Ubuntu LTS 10.04, that version will effectively be the end of the 2.6 line for many places if version numbers jump like this. The kernel versions actively targeted by the -stable team [linux.com] are the only ones some people (including me) are interested in, and this cluster of distributions on 2.6.32 is a good thing in my book. The main issues I'm seeing in newer kernels that I'm concerned about backports of are the continued fixes to weird ext4 bugs happening in newer kernels. Keep those coming, backport drivers for the most common hardware out there, and the rest of the kernel development can march along without me being so worried about it. (Context disclaimer: I worry about PostgreSQL database servers for a living, so my customers are more paranoid about stability than most)

    The eventual release of btrfs is one of the things I'd would be glad to see happen only in a kernel that's clearly labeled part of new, less stable development. New filesystems are one of the hardest things to get right, and there's no other class of bugs as likely to lead to major loss of data.

    • The eventual release of btrfs is one of the things I'd would be glad to see happen only in a kernel that's clearly labeled part of new, less stable development.

      Linus is not proposing to create a less-stable development branch. He's not proposing to change the kernel development process at all, just to change the numbering because the major number has become completely useless, the minor number has become somewhat useless and the sub-minor number (where all the action happens) is getting awfully big. Every kernel release will still be considered basically-stable, with the distros being left to do whatever final stabilization is needed.

      • Yes, that's what Linus will say. I was commenting on how businesses will perceive things, regardless of the technical message that comes along with it. "2.8.1" or even worse "3.0.1" will be considered toxic no matter how it's presented to business people. And with so many distributions lined up with the same kernel version right now, it's a decent time to do it; I think the sort of places that think like that will be happy with the currently available options until enough Linux version bumps that the num

        • Given the roughly quarterly release cycle, version 3.1 will be out shortly after 3.0 anyway, so even if people are leery of 3.0 that will be a short-lived problem.

    • Re: (Score:3)

      by Rich0 ( 548339 )

      Btrfs is already in the kernel. Removing the experimental tag in the config item won't in itself cause any more instability.

      The only reason I could see forking a new branch is if integrating btrfs required making changes to a higher layer in the kernel (which the filesystem drivers plug into). Changes contained within the filesystem driver don't impact people who don't use that filesystem, or enable support for it when building their kernel.

      Branching the entire kernel codebase should be reserved for major

  • So Torvaldis is THINKING of changing the version number? Doesn't that basically mean that the number is entirely arbitrary and thus it doesn't make a difference?

  • Aren't we a bit late for an April fools day joke?

  • We use a dating system due to the large number of minor revisions, but keep the major revision number - so for instance,

    1.2011.03.23.1 := The first minor revision of version 1 of the software that took place on 23rd March 2011.
    It gives us the best of both worlds. We spent way too long coming to that solution, but it suits us a lot.

    Maybe for Linux it may make sense to move the first minor revision to the left of the revision date.
    Outside of that, subdivisions become pretty meaningless anyhow.

    If I were Linus,

    • Re: (Score:2)

      by youn ( 1516637 )

      I dated a cute minor revision once, she was sweet and all but had an inferiority complex. Then after she upgraded (plastic surgery), there were major incompatibilities ;). So how does that minor revision dating work, you have a dating web site? Or, when you have rules, because you do that quicker, it is called speed dating? and the major question is mark zuckerberg involved in this version social network?

    • Those revision numbers of yours are huge. I think it'd be easier to remember them if you used alphabetics for the month (e.g. 1.2011.Mar.23.1), but they're still unwieldy. If you want to use a date, I'd much prefer an Ubuntu-style convention. Whether or not you like Ubuntu, the version numbering is very sensible -- enough digits to tell you what you need to know, but few enough that it's very easy to remember. Actually, it might be even better just to use YY.V, where V is incremented with each release a
  • when ending existing series in an open ended fashion that allows for producing new seasons and movies that is - 'Our fight really begins here on !'

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close