cargo-semver-checks checks almost entirely only major.minor versioning issues. Rust's flavor of semver doesn't impose or demand any particular rules about what is a minor and what is a patch version.
So I'm a bit confused about the position you seem to be arguing against, when the tool and the entire ecosystem are doing exactly what you (AFAICT) consider a good idea.
Semantic Versioning 2.0.0
Summary
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backward compatible manner
PATCH version when you make backward compatible bug fixes
Three fields. If you're saying that cargo-semver-checks doesn't need three fields, then you're saying that it doesn't benefit from semver as defined by semver.org.
I don't really follow this comments. It's a bit too rambly and circuitous for me to follow, and I gave it a few tries, but I do admit I'm not the best at reading walls of text.
From what I can tell, you're trying to argue that semver is useless while also saying that not following semver means that you don't get any benefits, but that just doesn't seem like a proper argument, so I'm surely misinterpreting.
I think SemVer is a social construct, but that most of the time we can predict what changes will be breaking. We may get it wrong of course, but that doesn't mean we should throw our hands up and not try.
cargo-semver-checks checks for breaking changes. minor and patch versions are defined to be backwards compatible and therefore not breaking. So why would it distinguish.
For tooling it's very hard to detect between a feature and a bug fix so it's almost impossible to automate that series of checks
> Because as a user of semver, I am not checking for breaking changes. I'm checking if I need to update because of a bug.
Semver doesn't help you do that. If you're on version 1.0.1 of my software, and I update to version 1.1.0 and then 1.1.1, have I fixed a bug that exists in 1.0.1? There's no way for you to know based on the version number.
Knowing whether you need to update because of a bug is something you can only find out from change logs, not from version numbers.
So I'm a bit confused about the position you seem to be arguing against, when the tool and the entire ecosystem are doing exactly what you (AFAICT) consider a good idea.