Announcement

Collapse
No announcement yet.

Linus Talks Of Linux 2.8 Or Linux 3.0; Ending Linux 2.6

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Linus Talks Of Linux 2.8 Or Linux 3.0; Ending Linux 2.6

    Phoronix: Linus Talks Of Linux 2.8 Or Linux 3.0; Ending Linux 2.6

    In a message to the Linux Kernel Mailing List today regarding the shortened merge window for the Linux 2.6.40 kernel, Linus Torvalds brings up that there's already been many Linux 2.6 kernel releases and that he could end up tagging this as the Linux 2.8.0 kernel...

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

  • #2
    and in that case, it really would be "3.0", not "3.0.0" - the stable team would get the third digit rather than the fourth one
    That is a good change.

    Comment


    • #3
      Are major versions not ment for big changes.

      Hmm, I always thought going up a major (or even a minor) meant a big time change with loads of incompatibilities. Has the Godfather already decided on what he'd want to break?

      Comment


      • #4
        The current version number scheme is wrong anyway. With the model now used by the kernel, it makes more sense to release the next version as 2.7.0 and drop the fourth number completely. What use does it have anyway? After 2.7.0 is released, merge window for 2.8.0 opens, and updates to the current stable kernel should be tagged as 2.7.1, 2.7.2, etc.

        Edit:
        Also, they shouldn't be afraid to increase the major number. For example, removing the BKL was big enough of a change to go to 3.0.0.
        Last edited by RealNC; 05-23-2011, 05:10 PM.

        Comment


        • #5
          I personally like a "3.0" better (2 digits), rather than "2.8.0" (three digits).

          Besides, the "two" (in 2.x.x) doesn't mean anything any longer since no one in his right mind is using any Linux version prior to 2.x.x imo.

          Comment


          • #6
            Originally posted by cl333r View Post
            I personally like a "3.0" better (2 digits), rather than "2.8.0" (three digits).
            Well, 3.0 would technically be 3.0.0. It's just that usually when there's two 0's in a row, the last isn't written. So it would be 2.8. Only the first update to it would be written as 2.8.1.

            It's like we have now. 2.6.39 got released, not 2.6.39.0. But the first update to it will be 2.6.39.1.

            Comment


            • #7
              He should scrap the 2.6.40 to 6.40. The first number is useless now that it everybody knows that the first stable release of Linux, ever, has been delivered a very, very, very long time ago. Uneven like 2.6.39 indicates unstable and 2.6.40.indicates stable. The first number is absolutely useless nowadays.

              Now the second number 2.6.40 indicates an acrhitecture overhaul. So either keep 6 or dare to make a 2.7.0 kernel change towards a stable 2.8.0. I don't think that it would be a problem if the code stays the same but with slow modularization over time. 2.7.1 indicating unstable and 2.7.2 indicating the first stable release. Having 2.8.0, or rather 8.0, as a modular kernel.

              The kernel is getting fat. I think taking modular design beyond kernel modules is great. I don't think that breaking stuff is good. I'd say pull a Gnome 3.x at the incremental change planning of Gnome 2.x.

              Anything else in terms of versioning numbers is total horror and only useful as Wine now has a 'useful' 1.x version scheme while I wished they still 0.9.x'd the sucker.

              Comment


              • #8
                About time. I was beggining to think that the 2.6 kernel would go into the hundreds...

                Comment


                • #9
                  My take on this is version numbers should attempt to be informative or at least avoid being misleading. So they can be based on some milestone, like Wine 1.x, or reflect major architectural changes.

                  Now I'm not sure any of that holds for Linux, and there doesn't seem to be any significant mid/long-term roadmap. This is okay and maybe natural for such a project, as opposed to, say, Wine, as it's difficult to objectively score achievements (see server vs desktop users). Well, the BKL removal is one important change, but it's not like it happened overnight or like it's something a user can directly experience and benefit from.

                  And numbers aren't really getting big: it's going to be a long time before we see even 2.6.100.

                  The development model is suited to incremental but significant changes, and this isn't going to change any time soon. It's tempting to say "hey, let's take this opportunity to make some major changes or go into a freeze or both", but that probably isn't better.

                  So unless there's a half-good reason to do that, I'm not sure this change is warranted. And it's probably better if Linux doesn't get a marketing department.

                  Comment


                  • #10
                    Actually, Linus' latest idea of going 3.x with x being the minor isn't bad at all, as long as we don't go 4.x after 3.40

                    Comment


                    • #11
                      In a numbering system sense it wouldn't be the best idea, but I think it would be hilarious if he changed the next kernel version to 2.7 as a way of poking fun at SCO's ridiculous argument years ago that code for the Linux 2.7 kernel was stolen from them.

                      Comment


                      • #12
                        i don't understand exactly why they skip over odd numbers (2.7 and 2.9) and imo, if they were going to move to 2.8.0 or 3.0.0, they should have done that when ditching HAL for udev. to me, that was a pretty big change for the kernel. i feel like new version numbers are just thrown out arbitrarily and i really don't like it - except for the very last digit, there doesn't appear to be any particular meaning to any of the numbers.

                        i agree with the guy who wants to do version numbers by date. considering linux has been stable for about a full decade, we're just going to either go up in little increments like 2.6.37, .38, .39, .40, and so on, or, we're going to go up from 2.6.40 to 3.0.0 without any particular reason.

                        i feel like 2.7 should be the next number, and 2.7 should not be breached until all KERNEL related current issues (such as the power regression) are fixed. but like stated before, we should have been in 2.7 a long time ago when HAL was replaced.

                        Comment


                        • #13
                          Originally posted by RealNC View Post
                          The current version number scheme is wrong anyway. With the model now used by the kernel, it makes more sense to release the next version as 2.7.0 and drop the fourth number completely. What use does it have anyway? After 2.7.0 is released, merge window for 2.8.0 opens, and updates to the current stable kernel should be tagged as 2.7.1, 2.7.2, etc.

                          Edit:
                          Also, they shouldn't be afraid to increase the major number. For example, removing the BKL was big enough of a change to go to 3.0.0.

                          Yes something as major as removing the BKL code or major infrastructure/ABI changes should warrant a major version bump. It should have been considered before, as even the 2.4 series has like 37 revisions already.

                          Comment


                          • #14
                            I like the idea of using the year and month of release for the numbering system.

                            Comment


                            • #15
                              Odd for Development

                              Originally posted by schmidtbag View Post
                              i don't understand exactly why they skip over odd numbers (2.7 and 2.9)
                              Historically, the odd minor revision numbers were the unstable releases where new features would be introduced. ALSA, for example, was introduced in the 2.5 series, then became part of the stable 2.6 kernel. Now that new features are regularly introduced to the kernel, this may change.

                              Comment

                              Working...
                              X