Just because one person doesn't find a piece of information useful doesn't mean that everyone else doesn't. Semver is a useful foundation to build versioning semantics upon, and nothing more. I find all three components to be useful for communicating the scope of changes in any given version, and tools like the OP that enforce these assumptions make semver even more useful. If you think that patch versions are useless, then you're free to omit them in your own libraries.
I never said patch versions are useless. I pointed out that minor and patch versions in the semantic versioning are not very different from each other, in particular compared with major versions. I do use three-part versions, as people had done much before the semver, but people also have used two-part versions and decimal-based versions, not to mention multiple flavors of four-part versions as well. And tools like cargo-semver-checks are actually useful even in the absence of any versioning, because they directly tell which version is compatible with others. They make semver (or any other versioning schemes) more useful, but semver does not make them useful.
If I seem to attack a weird strawman, you are not very wrong. Semver is useless but doesn't hurt much either. Semver can somehow encode one-part and two-part versions as well by appending excess zeros. I'm much more concerned that embracing semver (or really any other alternative versioning scheme) makes us overlook the actual problem---versions may detect but can't fix breaking changes. A vast majority of breaking changes is mechanically fixable, and we all know how it is beneficial. We should embrace a method to reduce perceived breaking changes, not a method to point out possible breaking changes.
> A vast majority of breaking changes is mechanically fixable, and we all know how it is beneficial. We should embrace a method to reduce perceived breaking changes, not a method to point out possible breaking changes.
These seem like entirely distinct goals that should be pursued separately. Yes, from the perspective of a library consumer, any breaking change is a problem. But from the perspective of a library author, there's a crucial distinction between breaking changes that I intended to make and breaking changes that I didn't intend to make. The tool in the OP is for use by library authors, with the goal of eliminating unintentional breaking changes, and thereby reducing the number of breaking changes that my users are forced to endure. And what you're asking for is a tool to be used by library consumers, in order to mitigate intentional breaking changes. Both these tools can exist, and both benefit (at least marginally) from semver. Semver isn't a panacea, it's just the simplest possible foundation to communicate ideas about versioning. It's entirely welcome to invent concepts beyond semver to perform even more advanced communication.
