4 ms·

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

• 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.