> Great, you agree then that this tool is useful because it will help you try to predict whether a change will break compatibility.

No. I guess you didn't actually read what I said, and decided instead to construct a strawman by carving very few words out of it completely ignoring the rest of the words around them.

> I can barely follow the rest of your comment.

Ah ha.

> Semver is useful in, at least, a decentralized set of actors trying to minimally cooperate with one another by using a short number to communicate coarse but important information with respect to compatibility.

It's not any more useful than a system with only either date/incremental (this is newer than that) or major.minor (I promise that this change breaks, and that other change might also break but I hope not) versioning except for the one case I mentioned, which FOSS decentralization has absolutely nothing to do with.

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.

> Rust's flavor of semver doesn't...

Semver.org says:

  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.

I added a tldr to the top of my original comment. I hope it helps.

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

> minor and patch versions are defined to be backwards compatible and therefore not breaking. So why would it distinguish.

Indeed, why? And yet semver itself does, which is senseless.

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.

As a user updating my software it's nice to know the gist of an update at a glance.

As a piece of software looking for breaking changes, it is unnecessary to consider.

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