• Baron Von J@lemmy.world
    link
    fedilink
    arrow-up
    4
    arrow-down
    1
    ·
    2 days ago

    A breaking change should have been 2.0, not a new 1.<minor> release.

    It should still be 0.<minor> if they’ve not reached the stability for keeping backwards compatibly in all 1.x releases.

    • LeFantome@programming.dev
      link
      fedilink
      arrow-up
      2
      ·
      1 day ago

      I was going to say you are wrong about semver but you are correct that it should simply not be version 1 yet.

      To quote semver.org: “Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.”

      If they had just done that, their disclaimer would be implied. Once it is 1.0, breaking changes require a major version change. That seems like reasonable policy to me.

      That said, I upgraded without issue.

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

      To quote them:

      We are still in a fast development cycle, so the versioning is to keep track of the progress/iteration of the project. When a stable release is reached (2?), then any breaking change would require more proper major version changes

      • Baron Von J@lemmy.world
        link
        fedilink
        arrow-up
        8
        ·
        2 days ago

        Yes, I understand they have declared that. Their declaration does not, however, negate the common semantic versioning standards, found at semver.org. These common standards are significant for admins running shared systems where they automatic upgrade processes based on common semantic versioning rules. The software will stabilize and they will adopt a more stringent policy. But they should still be releasing 0.x versions since they’ve not yet reached it.