4 ms·

It seems to me that they bumped the major version for every breaking change in the changelog. I guess that is in strict compliance with semantic versioning but

It seems to me that they bumped the major version for every breaking change in the changelog. I guess that is in strict compliance with semantic versioning but indeed it looks strange.

NetOpWibby 4y ago
Wild, seeing SemVer actually used properly.
- Arainach 4y ago
  You don't need to do a new release for every checkin. You can make a series of breaking changes and only then declare a new release, bumping the version number. After all, it took (at least) 21 years to get from 0 to 3.0.0 There's absolutely no reason for 2 major bumps 11 days apart.
  - egwor 4y ago
    If you’re doing CI/CD, though, you should expect this kind of thing. I do appreciate that maybe there could be a throttle for major bumps.
    - Arainach 4y ago
      If you're doing CI/CD and pulling from head rather than official published versions, you deserve what you get. If you mean the graphviz project itself, version numbers are meaningless to it internally.
  - The_Colonel 4y ago
    > You can make a series of breaking changes and only then declare a new release That means you need to postpone the breaking changes for a while, kind of bunching them together. Many projects do that, but it also incurs some cost. > After all, it took (at least) 21 years to get from 0 to 3.0.0 It's possible that they did not implement semantic changes in the strict sense before and included small breaking changes into non-major releases (I think a lot of software does this). Fast changes of version numbers may just mean they started reflecting each small BC break into the version number.
    - fourthark 4y ago
      Right, we are witnessing a project switch to semantic versioning that did not have it before. I don't know when semantic versioning was invented, but it only became prominent in the last decade. Graphviz is from the 90s.
      - zvr 4y ago
        Graphviz is from earlier than that -- mid to late '80s, I'd say. The first paper appeared in Software Practice and Experience in 1988.
- einpoklum 4y ago
  The thing is, if you're writing software with a lot of breaking changes, SemVer doesn't make much sense, because you'll just quickly get to major version numbers in the hundreds.
  - fourthark 4y ago
    Especially when the API surface area is as gigantic as graphviz's. Still, it's great to see new maintainers with bold ideas.
  - dragonwriter 4y ago
    > The thing is, if you're writing software with a lot of breaking changes, SemVer doesn't make much sense, because you'll just quickly get to major version numbers in the hundreds “The version number conveys whether there is a breaking change” seems more important than “the version number remains small”, so while the second half may be true, I don’t see how that supports the first half at all.
    - einpoklum 4y ago
      The problem isn't that it's small, the problem is that if few changes are breaking, then you have "version 5" which is significantly different than "version 4". Is version 465 very different from version 464 though?
      - justsomehnguy 4y ago
        /me points at Firefox
        ivanche 4y ago
        A bit unfair, no? Firefox switched to the "new major version every 6 weeks (or so)" only because Google did that first with Chrome, and people started thinking "Chrome is so much better because it's in version 17 and Firefox is version 3".

It seems to me that they bumped the major version for every breaking change in the changelog. I guess that is in strict compliance with semantic versioning but indeed it looks strange.

NetOpWibby 4y ago

Wild, seeing SemVer actually used properly.

Arainach 4y ago
You don't need to do a new release for every checkin. You can make a series of breaking changes and only then declare a new release, bumping the version number. After all, it took (at least) 21 years to get from 0 to 3.0.0 There's absolutely no reason for 2 major bumps 11 days apart.
- egwor 4y ago
  If you’re doing CI/CD, though, you should expect this kind of thing. I do appreciate that maybe there could be a throttle for major bumps.
  - Arainach 4y ago
    If you're doing CI/CD and pulling from head rather than official published versions, you deserve what you get. If you mean the graphviz project itself, version numbers are meaningless to it internally.
- The_Colonel 4y ago
  > You can make a series of breaking changes and only then declare a new release That means you need to postpone the breaking changes for a while, kind of bunching them together. Many projects do that, but it also incurs some cost. > After all, it took (at least) 21 years to get from 0 to 3.0.0 It's possible that they did not implement semantic changes in the strict sense before and included small breaking changes into non-major releases (I think a lot of software does this). Fast changes of version numbers may just mean they started reflecting each small BC break into the version number.
  - fourthark 4y ago
    Right, we are witnessing a project switch to semantic versioning that did not have it before. I don't know when semantic versioning was invented, but it only became prominent in the last decade. Graphviz is from the 90s.
    - zvr 4y ago
      Graphviz is from earlier than that -- mid to late '80s, I'd say. The first paper appeared in Software Practice and Experience in 1988.
einpoklum 4y ago
The thing is, if you're writing software with a lot of breaking changes, SemVer doesn't make much sense, because you'll just quickly get to major version numbers in the hundreds.
- fourthark 4y ago
  Especially when the API surface area is as gigantic as graphviz's. Still, it's great to see new maintainers with bold ideas.
- dragonwriter 4y ago
  > The thing is, if you're writing software with a lot of breaking changes, SemVer doesn't make much sense, because you'll just quickly get to major version numbers in the hundreds “The version number conveys whether there is a breaking change” seems more important than “the version number remains small”, so while the second half may be true, I don’t see how that supports the first half at all.
  - einpoklum 4y ago
    The problem isn't that it's small, the problem is that if few changes are breaking, then you have "version 5" which is significantly different than "version 4". Is version 465 very different from version 464 though?
    - justsomehnguy 4y ago
      /me points at Firefox
      - ivanche 4y ago
        A bit unfair, no? Firefox switched to the "new major version every 6 weeks (or so)" only because Google did that first with Chrome, and people started thinking "Chrome is so much better because it's in version 17 and Firefox is version 3".