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

  • #21
    Personally, I'd love it if they moved to time-based versioning, i.e. 11.8 (August 2011), 11.11 (November 2011) or to something closer to what chromium does: 40, 41, 42 for each release (drop 2.6, it doesn't offer anything other than nostalgia, everything else can be tracked through the git hashes).

    People put way too much emphasis on useless fluff such as detailed version numbers.

    Comment


    • #22
      My take of what each number should mean:

      Major: Huge architectural changes or userspace stable API breakage. So 2->3 would mean something like, Fedora 15 would not even run correctly on Linux 3.0. This is what the kernel *currently* uses the minor number for. Evidence: Try running Linux 2.4.x on a reasonably modern distro. Hardware support aside, I don't think you would be successful in any capacity because so many features depend on 2.6 functionality. In fact, some features depend on at least a certain micro version of 2.6, like 2.6.8 or 2.6.18. And then some filesystems (ext4) didn't even exist in 2.4, and they've never (AFAIK) been backported.

      Minor: Stable releases representing significant feature development, but evolutionary. This is what the kernel *currently* uses the micro number for.

      Micro: Bugfix-only maintenance of a minor release. This is what the current *currently* uses the nano number for.

      Nano: Distros that have their own patch series should use the nano number, followed by the distro name. Making this somewhat standard would help with version tracking. And no, I absolutely hate the dash that all the distros tend to put after the micro number as it stands. Don't write "2.6.32-78-ubuntu1"; write "3.1.2.78ubuntu" (that would be the third-generation kernel, the first significant evolutionary release, the second maintenance release of 3.1, and the 78th patch release of said kernel by the Ubuntu kernel team. If the kernel team insists on keeping the same patch release and making a patch or fix to the patch (or to the package build), just tack on a number after the distro name, as most distros currently do.
      Last edited by allquixotic; 24 May 2011, 11:19 AM.

      Comment


      • #23
        Originally posted by allquixotic View Post
        My take of what each number should mean:

        Major: Huge architectural changes or userspace stable API breakage. So 2->3 would mean something like, Fedora 15 would not even run correctly on Linux 3.0. This is what the kernel *currently* uses the minor number for. Evidence: Try running Linux 2.4.x on a reasonably modern distro. Hardware support aside, I don't think you would be successful in any capacity because so many features depend on 2.6 functionality. In fact, some features depend on at least a certain micro version of 2.6, like 2.6.8 or 2.6.18. And then some filesystems (ext4) didn't even exist in 2.4, and they've never (AFAIK) been backported.

        Minor: Stable releases representing significant feature development, but evolutionary. This is what the kernel *currently* uses the micro number for.

        Micro: Bugfix-only maintenance of a minor release. This is what the current *currently* uses the nano number for.

        Nano: Distros that have their own patch series should use the nano number, followed by the distro name. Making this somewhat standard would help with version tracking. And no, I absolutely hate the dash that all the distros tend to put after the micro number as it stands. Don't write "2.6.32-78-ubuntu1"; write "3.1.2.78ubuntu" (that would be the third-generation kernel, the first significant evolutionary release, the second maintenance release of 3.1, and the 78th patch release of said kernel by the Ubuntu kernel team. If the kernel team insists on keeping the same patch release and making a patch or fix to the patch (or to the package build), just tack on a number after the distro name, as most distros currently do.

        this is an excellent collection of ideas and this is exactly what SHOULD be done, but we all know this isn't going to happen, which is unfortunate. like stated in my previous post, i think versions based on date would be more effective because in reality, what is the likelihood of linux reaching version 3.0 for a GOOD reason? its been 7 years, which is a very long time for such a young OS.

        Comment


        • #24
          Originally posted by AnonymousCoward View Post
          Whenever there were major kernel changes in the past Linus never thought it was necessary to bump the major version number. But now when there are no major changes he wants to change to major version number because "the voices in his head" tell him so? Wtf?

          Talk about irrational behavior.
          Nothing has been that major. And people have been telling him for a long time that he needed to change the version number scheme, so now that he is finally coming around to their arguments he's irrational?
          And why is it that whenever Linus travels abroad everybody else has to adjust to that?
          Because they all agreed to. Seriously, everyone has agreed that Linus is a good maintainer and it makes sense for him to be the guy at the top handling it. The distros all used to maintain their own heavily patched kernels, and it was widely agreed to be a terrible solution which is why they changed the way the 2.6 kernel was developed and managed. Anyone who disagrees with this is free to create their own kernel. They can even port patches from Linus's kernel into theirs to their hearts content. There's nothing special about Linus's kernel at all, except that everyone important has agreed that it is.
          No wonder the Android developers and so many others shun upstream development and prefer to work on their own copy of the kernel, where they are not subject to the whim of this dictator.
          Android is basically forced to keep their own copy because of all the crazy demands from the phone manufacturers. Ask them and they will flat out tell you they wish they could do the sane thing and live upstream, but it just isn't possible. The blame does not lie with Linus.
          I'm looking forward to the day when there can be some sanity to Linux kernel development. But I'm afraid it will be a long wait. Linus will never step down, his ego is just too big, and everybody else is either afraid of him or think he's some holy god.
          Linus will step down eventually, and someone from Red Hat will step up to replace him. There will no doubt be an uproar about how they are favoring red hat and trying to kill of BSD, or some nonsense. And things will continue much the way they already are now.

          Comment


          • #25
            All is good as it is.
            If one want to see versions like 6.40, he should think, is it good to have versions numbered like 26.40? I see just numbers, they can tell nothing about a hard work behind the scene.

            Comment


            • #26
              Originally posted by wstorm View Post
              All is good as it is.
              If one want to see versions like 6.40, he should think, is it good to have versions numbered like 26.40? I see just numbers, they can tell nothing about a hard work behind the scene.
              Exactly.

              Which was more work 2.6.40 or 2640? Neither. These are just numbers.

              Really, the only thing they need to do is increase monotonically. x.y is exactly as good as x.y.z or xyzw - it really doesn't matter. (Except if you are Apple - then you can turn a number into something worthy of worship )

              Comment

              Working...
              X