4 ms·

I think that "major.minor" is a useful feature of semantic versioning, that you can specify breaking changes vs non-breaking changes. "Announcement" version num

I think that "major.minor" is a useful feature of semantic versioning, that you can specify breaking changes vs non-breaking changes. "Announcement" version numbers may also be useful, although perhaps not as much, it seems to me. However, one thing I think would be useful is numbering of versions of "configuration-safe" upgrades.

seveibar 3y ago
In my original commit I wrote "BIGRELEASE.MAJOR.MINOR" but I realized in practice many packages start to bundle multiple changes into their MAJOR and sometimes even MINOR releases. To me this started to really confuse SemVer, ANNOUNCE/INCREMENT is comparatively a bit cleaner/more like what they were doing in practice (see the NextJS example)
- kijin 3y ago
  Whatever you call it, there needs to be some distinction between breaking changes and other changes. It doesn't need to be as prominent as the marketing-oriented big release, but it needs to be in there somewhere. Modern software projects have too many dependencies, and too much noise coming from each dependency. Your project is likely just one of hundreds of libraries that got pulled into my dependency graph for some reason. I want to know if, and only if, there's a change that I need to be aware of. As for that shiny new feature that you're really proud of, I shouldn't even notice it unless it breaks an existing API.