[aurelianito]

Semver is based on a lie. It assumes that you can define what is the proper behavior of a library. That's not necessarily true, and can be subtlety false, and different depending on the use case. I can think on some situations where I trusted semantic versioning and it bited me when an update was made. I am not talking about new bug introductions. I assumed behavoir that the library owner assumed as not important.

[gpm]

"All models are wrong, but some are useful".

Yes, no matter how hard you try semver will sometimes get it wrong, but as long as it usually doesn't it's still useful to let my tools do their best at automatically selecting a version of the library that will be compatible with every part of my application that cares, and that has had as many bugs fixed as possible. That's what semver allows cargo to do, and 99.9% of the time it just works. 0.1% of the time you have to manually intervene, and that's ok. It's better than having to manually intervene 100% of the time, or the old-school C solution of "just pick whatever is lying around on the OS and hope it works/is compatible".

[cmrdporcupine]

In the end it's why Google insists on "vendoring" (checking in) third party dependencies and only having one version of a dependency for the entire (massive) mono repo and designated maintainers. You want a new version? Put a ring on it. Test it, and maintain it.

At first I thought it was insanity. Now, buried in a maze of transitive third party and first party dependencies scattered across multiple git repositories and crates, I really really miss it.

Of course like many other things there it depends on having lots of well-paid staff, without deadline guns to their head, committed to code quality and infrastructure.

[williamdclt]

Because it’s not perfect doesn’t mean it’s useless. If semver correctly describes 90% of behaviour changes (random number), that’s a significant load off my plate as a lib user

[esafak]

You should write tests to catch such changes.