• 3abas@lemmy.world
        link
        fedilink
        arrow-up
        6
        ·
        2 days ago

        The blog post is confusing, but the image is very clear.

        5.2.0 was released. Then 5.2.1, 5.2.2, 5.2.3, 5.2.4, 5.2.5, and 5.2.6 were released as stable updates. Pretty straightforward.

        After 5.2.0 came out, normal development continued toward the upcoming 5.3.0 in Linus’s mainline tree. As bugfixes for real problems (crashes, data corruption, build breaks, security issues, etc.) were written and merged into mainline, a subset of those fixes was then backported to the 5.2.y stable branch and released as 5.2.1, 5.2.2, and so on.

        In other words, there is a separate 5.2.y branch, but most of its changes are not developed there first. They are developed in mainline (the code that will eventually become 5.3.0 and beyond) and then cherry-picked back into 5.2.y as “stable” bugfixes. There is no “merge 5.2.x back into 5.3.0”; instead, stable only takes fixes that are already in mainline.

        This means that any fix you see in a 5.2.y release should already be present in the mainline code that leads to 5.3.0 (or replaced by an equivalent fix there). So when you move from 5.2.6 to 5.3.0, you should not lose any of the bugfixes you were getting from the 5.2.y stable series.

        • erebion@news.erebion.eu
          link
          fedilink
          English
          arrow-up
          2
          ·
          2 days ago

          Sure, but I still don’t understand why they decided against semantic versioning. That way people would be far less confused.

          • RedWeasel@lemmy.world
            link
            fedilink
            English
            arrow-up
            2
            ·
            1 day ago

            If semantic versioning is:

            MAJOR version when you make incompatible API changes MINOR version when you add functionality in a backward compatible manner PATCH version when you make backward compatible bug fixes

            then I think that would be on like 3.77.0 or something right now. Not terrible, but honestly prefer it to be like the major upped in the new year every year. It is about 43 years old,so 43.x in 2026. Would be easier to know how old a kernel release is without looking it up.

            • Arthur Besse@lemmy.mlOPM
              link
              fedilink
              English
              arrow-up
              1
              arrow-down
              1
              ·
              12 hours ago

              Would be easier to know how old a kernel release is without looking it up.

              I concur, but it would be much easier to make the major version the current year (as many projects do, and Linux should imo) rather than the whole project’s age at the time of a release.

              Linux is only 34 years old, btw.

              • RedWeasel@lemmy.world
                link
                fedilink
                English
                arrow-up
                2
                ·
                7 hours ago

                I must have been tired when I did that math. I’d be happy with the year as well. Just don’t use the firefox/chrome model.

    • eldavi@lemmy.ml
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 day ago

      even once you do get it; you’ll forget it and then you’ll see posts like this reminding you of it all over again. lol