If semver suggests a release isn't breaking, in Rust it overwhelmingly isn't breaking. Around 3% of the time, assuming you use every obscure bit of public API in the library, you might get broken by a release when you shouldn't be. In practice, that percentage is way lower than that: nobody uses the entire public API of anything, or comes anywhere close. That's why the post says these semver violations were unknown, even though most of them were multiple years old. If something breaks, and you weren't using it anyway, you were not broken.

The post is emphatically in favor of semver as used by Rust, because it has clear benefits and works great the vast majority of the time. The part that we want to make better is to lower the odds even further that an accidental breaking change breaks a bunch of people's code and ruins their day.

No single technique can do that: not testing, not fuzzing, not cargo-semver-checks. But a sound combination of techniques can drive the odds to damn near zero for all practical purposes.

I'm sure someone could build a semver-checker for Python or JS or Java or whatever, and I'd even be willing to help them and walk them through how cargo-semver-checks works. But in Rust, a big driver of adoption is that Rust and cargo are opinionated about things, so people adopt cargo-semver-checks not necessarily out of love for semver but out of a desire to not wake up to 100 people being upset in their GitHub issues about broken builds. The adoption situation might be harder for other languages with less opinionated versioning stories.

Rust compatibility (thus versioning) is fairly fragile due to its relatively powerful type system, and yet:

>Around 1 in 31 releases had at least one semver violation

Abandoning semver means making it worse 30 out of 31 times for a fragile language, or likely more (because you do not always use the thing that technically broke, or in a way that notices the break). Other languages generally have even stronger arguments in favor of semver.

It's not a "both sides" thing, semver wins by an absolute knockout in every conceivable way, and especially in practical day-to-day ways. Anyone opposed to it does not know what they're talking about, or they're simply trolling, and it shows. There could definitely be better systems, but "just don't use semver lol" is not one of them.

If the hints are sometimes incorrect, should we trust them? Isn't it the same release-verification legwork either way? If so, what's the point of the hint?

> Rust compatibility (thus versioning) is fairly fragile due to its relatively powerful type system, and yet:

Yes, I'm speaking about SemVer, which was neither invented by nor solely implemented in Rust. I understand that this blog post is about SemVer in Rust.

> Abandoning semver means making it worse 30 out of 31 times for a fragile language, or likely more (because you do not always use the thing that technically broke). Other languages generally have even stronger arguments in favor of semver.

I read this as: tooling is required to verify a release does or does not break a contract defined by a library, regardless of versioning strategy. It's not like we're talking about 1 in a million here.

> Anyone opposed to it does not know what they're talking about, or they're simply trolling, and it shows.

Ahh yes. "I'm right and if you disagree you're wrong". The ultimate debate tactic. I'll skip the rest of this thread. Enjoy the day!

No, as it turns out it very much is not even close to the same amount of legwork.

> I read this as

I don't think your attempt at a re-statement is accurate to the source. Also, "regardless of versioning strategy" is simply not an option in Rust, since the entire ecosystem is opinionated about how versions should work and overall everything works very well.

This post is about taking something that is already very rare (though painful when it does happen!) and making it even more rare. It shows a concrete way to do so, and also shows that so far we've been "getting lucky" by experiencing breakage less often than we might have been, given the same code changes.

In other words: `cargo update` today has a tiny chance of breaking your Rust project. But if everyone used `cargo-semver-checks` every time, as demonstrated by what the blog post's analysis caught, we'd reduce the number of accidentally-breaking releases by *3% of all releases*. That is an astoundingly high reduction, so coupled with good testing practices and other static checks (type system, borrow checker, etc.) it means that `cargo update` will be even more astonishingly unlikely to break your project.

It works the vast majority of the time. Many, many studies across many languages repeatedly show it. There are flaws, but there are extremely clear benefits - most updates just work, automatically. It works so well most people don't even realize how much they're being protected from.

So what are you gaining by abandoning it? You're losing a lot, if you're not gaining a lot in return then there's no reason to choose it.

---

>Ahh yes. "I'm right and if you disagree you're wrong". The ultimate debate tactic.

I agree in principle, but it is also simply true in some cases. It's like arguing against vaccines or range checks on arrays - there's a massive load of trolling or willful ignorance in semver debates. There can definitely be better systems, but none are used widely enough to be noteworthy to most, and most presented alternatives are laughably bad to anyone who has done anything but throw nonsense at the internet's wall and see what sticks. Some things are just not that complex, and armchair bullshitters can be spotted miles away.