Announcement

Collapse
No announcement yet.

The Community Really Wants To See Linux 4.0

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

  • The Community Really Wants To See Linux 4.0

    Phoronix: The Community Really Wants To See Linux 4.0

    Linus Torvalds has yet to reveal whether Linux 3.20 will be re-branded as Linux 4.0, but it seems the community at least really wants this version bump to happen...

    http://www.phoronix.com/scan.php?pag...0-Voting-56-44

  • #2
    I would call 56% vs 44% as leaning a certain way, not "really wants".

    Comment


    • #3
      I think it is incredibly stupid to have versoning that does not mean anything at all. When every other project in the universe either does major.minor.patch where major means backwards breaking changes, minor means non-breaking changes, and patch means security and bug fixes.

      Linux mostly follows that, except as Linus says they will never break userspace (which I also disagree with, the kernel will turn into an NT like nightmare in 20 more years if you never break userspace to fix critical security vulnerabilities or colossal code rot of unused features) so the major version never has a reason to progress.

      So why the hell not get rid of it? Make Linux minor.patch. There are other nomenclatures but you do need some versoning system for Linux that denotes both feature changes and security changes, because you always, no matter what, want the latest patch kernel, but may not want to adopt newer releases of the kernel.

      But even the systemd "every version is an incremental number" makes more sense that a pointless major version. Throw a patch on the end and you have minor.patch. Or Ubuntu style time stamp releases, maybe with a patch on the end, like 2015-03.5 or something, though just incremental numbers are easier to understand.

      But versioning that does not mean anything defeats the purpose of versioning. 3.0 was meaningful because it fixed the broken versioning from the 2.6 series. But 4.0 has no meaning at all, and I cannot fathom why everyone thinks its a great idea to make the major and minor version numbers mean nothing for the most free important software project in the world. How the hell is 20 too big of a number? What does that even mean, that you have released too many kernels? Is systemd 218 too much to comprehend, is that why nobody likes it?
      Last edited by zanny; 16 February 2015, 11:42 AM.

      Comment


      • #4
        If there isn't going to be a set of major changes that drives up the major version, but just small incremental changes... I would be tempted to go the Ubuntu route and do "YY.MM". Many small incremental changes spanning multiple years renders your major version useless. You might as well keep it useful by letting it tell everyone when the thing was released.

        Comment


        • #5
          Originally posted by bpetty View Post
          If there isn't going to be a set of major changes that drives up the major version, but just small incremental changes... I would be tempted to go the Ubuntu route and do "YY.MM". Many small incremental changes spanning multiple years renders your major version useless. You might as well keep it useful by letting it tell everyone when the thing was released.
          I also think the "YY.MM[.patch]" makes a lot of sense for Linux version system, since (as zanny said) Linux commits are made so it never breaks the userspace, so there will never be ground breaking changes and thus no major version bumps.
          It is also very practical since it allows to easily now how old you kernel is.

          Comment


          • #6
            Originally posted by Creak View Post
            I also think the "YY.MM[.patch]" makes a lot of sense for Linux version system, since (as zanny said) Linux commits are made so it never breaks the userspace, so there will never be ground breaking changes and thus no major version bumps.
            It is also very practical since it allows to easily now how old you kernel is.
            i think month would be confusing a bit to track how much you're behind. not everyone knows release schedule

            better would be year followed by yearly versions.

            Comment


            • #7
              Originally posted by justmy2cents View Post
              i think month would be confusing a bit to track how much you're behind. not everyone knows release schedule

              better would be year followed by yearly versions.
              Well I think that anyone interested in the Linux kernel knows that there is a version every two or three months.

              Comment


              • #8
                "Overwhelmingly"? 56% is not quite the landslide you're painting it as.

                Comment


                • #9
                  Originally posted by justmy2cents View Post
                  i think month would be confusing a bit to track how much you're behind. not everyone knows release schedule

                  better would be year followed by yearly versions.
                  I don't know. See lets just say hypothetically a kernel gets released on march 2015 as 15.03.0 The version number is obviously the date it was released and point number is obviously a release version.

                  That would work, but it breaks Linus' no big number rule.

                  Comment


                  • #10
                    Originally posted by duby229 View Post
                    I don't know. See lets just say hypothetically a kernel gets released on march 2015 as 15.03.0 The version number is obviously the date it was released and point number is obviously a release version.

                    That would work, but it breaks Linus' no big number rule.
                    still, i wouldn't think year and big number would be confused. year is something people are used to.

                    bigger problem with month as second number would be "i want to roll back one release, where is the yy.m-1". speaking for me personally, i never liked ubuntu versioning. while year makes sense since it is consistent, skipping subversion number in order to specify month is not really making sense. makes rolling back lot more confusing

                    also, since 20 is already considered big number. wouldn't suggestion of 15.03.0 already impose temporary patch? what do you do in 5 years? adopt new versioning with year - 20?
                    Last edited by justmy2cents; 16 February 2015, 12:46 PM.

                    Comment

                    Working...
                    X