cargo-semver-checks VS rust-semverver

If you'd like to dig deeper, here are some links:

- cargo-semver-checks: https://github.com/obi1kenobi/cargo-semver-checks

- Trustfall query engine, which powers cargo-semver-checks: https://github.com/obi1kenobi/trustfall

- Trustfall playground, where you can query Rust library APIs in your browser -- for example, "which structs in `itertools` are importable by more than one path": https://play.predr.ag/rustdoc#?f=2&q=*3-Structs-importable-f...

- 10min conference talk on Trustfall: https://www.hytradboi.com/2022/how-to-query-almost-everythin...

I'm also giving a talk at P99 CONF in a few months about how Trustfall's new optimizations API made cargo-semver-checks over 2300x faster: https://twitter.com/PredragGruevski/status/16893002495908003...

I strongly recommend that anybody creating new error types for public APIs read Study of std::io::Error by u/matklad to see some ways that error types can [need to] be future-proofed. I don't know if cargo-semver-checks can catch these issues when they're generated by a macro, but it'd be something people using this crate should carefully look into.

cargo-semver-checks will implement a check for cases like this, and many other hazards like it. The check will be major, or minor, or just a hazard — whatever the overall community decides is right.

Full release notes: https://github.com/obi1kenobi/cargo-semver-checks/releases/tag/v0.18.0

Release notes, TL;DR: Rust 1.65+ only, no more false positives due to moved+re-exported items.

1) No. I think semver is just fine for its intended purpose. I mean, I'm sure its spec could be improved in various ways, but its fundamental idea seems fine to me. I think it's just important to remember that semver is a means to an end, and not an end itself. It is a tool of communication most useful in a decentralized context.

2) No.

3) See: https://github.com/rust-lang/rust-semverver --- But also, this is only ever going to be a "best effort" sort of thing. Semver isn't just about method additions or deletions, but also behavior.

How does this compare to cargo-semverver?

Found this: https://github.com/rust-lang/rust-semverver but it doesn't seem to act on git log/diffs... just FYI.

Enter rust-semverver!

Rust type system on the other hand does not allow this. Traits are monotonic logic: adding trait-impls / most qualifiers does't influence already existing and compiling code (note: for code that doesn't rely on disambiguation to compile). There's rules that clarify this disambiguations and breaking/non-breaking changes according to the type system. There's SemVerVer to automatically verify those guidelines.

In my case it wasn't so bad and an easy fix was fast to write, but it got me thinking of how much of a problem this is for the wider ecosystem. Some searching showed me, that of course there is a tool rust-semverver to do exactly that. Sadly it errors on my system (or maybe im just using it wrong). Would've been interesting to see how often this actually happens on crates.io and how much of a problem this really is.

There's been an attempt at this for the Rust ecosystem: https://stackoverflow.com/questions/41185023/what-exactly-is...

There's also a library that attempts to automatically check sermver adherence of a crate: https://github.com/rust-lang/rust-semverver

And there has been quite a bit of effort into preventing semver requirements from fracturing the ecosystem. This revolves around the compiler working with multiple major versions of a single library: https://github.com/dtolnay/semver-trick

Turns out it already exists: https://github.com/rust-lang/rust-semverver