1. 13

  2. 15

    Wow that sounds incredibly confusing and somewhat misleading based on how pretty much every release naming scheme works.

    1. 4

      That was my initial reaction as well.

      I wonder what happened to alpha and beta releases, and release candidates… Naming those “point zero” is very unnatural to me. I’m not saying that the point zero release must be perfect. I would just expect that, for a library, a point zero release indicates that the API is frozen for the current release cycle.

      And they can certainly come up with their own conventions. But choosing something that contradicts established patterns everywhere else is rather odd.

      1. 3

        Exactly, most people commonly understand version X.0 to be the first stable release, with an API that will be supported in the rest of the X.y releases.

        I can guess at why they don’t want to use beta, because it sounds like the pre-finalized versions are going to be around for a while before they’re determined to be stabilized, but that doesn’t make it any less confusing.

        Personally, I’d tend towards the Gmail approach of just calling it beta for five years after everything is stable, and finally removing the label because it’s become a running joke.

    2. 10

      “When someone says you hurt them you don’t get to decide you didn’t.” applies here.

      1. 7

        head scratch

        It may be that I’m low on sleep, but I find this very, very confusing.

        1. 5

          Not going to comment on whether it’s a good strategy, but I very much appreciate they are making an honest attempt at stability and compromise for desktop applications. My biggest gripe with the *nix desktop environments has been the massive ???? around versioning, compatibility, and stability.

          1. 3

            I think a better way to present the proposal would be to follow something like what browsers do:

            1. Every new release gets a new major version, because it’s API/ABI incompatible with everything previous
            2. Every release that’s divisible by 4 (that is, every two years) is an LTS (“long term support”) or ESR (“extended support release”) branch that people can use if they want stability.

            Of course, the difference with browsers is that most people use the regular releases because there’s a central core of stable functionality that every browser has in common, so even the latest incompatible release is never completely incompatible (for example, every modern browser renders the CSS Acid 2 Test identically), and browser vendors can use this rapid feedback loop to help settle things down before they get to the LTS/ESR releases.

            In the GNOME world, they’re encouraging developers not to try to keep up with the latest GTK+ releases, and I’m guessing they’re not making any promises about core stability, so very likely they won’t get very much feedback about their proposed changes, and it will be infeasible for anybody outside of RedHat/GNOME.org to develop for the GNOME desktop at all.

            1. 3

              Obligatory reference to https://www.jwz.org/doc/cadt.html

              1. 2

                It’s not exactly the same. CADT is about constant rewriting, this is about constant mutation.

                1. 2

                  “It hardly seems worth even having a bug system if the frequency of from-scratch rewrites always outstrips the pace of bug fixing. Why not be honest and resign yourself to the fact that version 0.8 is followed by version 0.8, which is then followed by version 0.8?”