Rust version requirement change as semver breaking or not

I generally try to guarantee a certain MSRV for my libraries. The rationale is that a certain workflow (e.g. weekly cargo test runs in CI on a certain test image) should not break suddenly without any change by the user. It just doesn't feel right if the entire CI workflow worked yesterday but breaks today because it does not use the very latest Rust version that was released just a day ago.

However, I feel this is a futile attempt. In the last two weeks I've had about a hand full of my crates break due to changed MSRV requirements in transitive dependencies deep down. Some examples lately are miniz_oxide, percent-encoding, mime-guess and some others that i forgot. I can try to follow a policy (like always bumping at least the minor version for MSRV changes), but I can't guarantee that policy if dependencies constantly change that requirement under my feet. And pinning all dependencies of a library isn't a solution either.

In some cases I've tried to publish a patch release that pins those dependencies to a fixed version in order to guarantee that MSRV, but it's just too much work if I have to do that every few weeks for a hand full of crates... I hoped that Rust 1.31 (Rust 2018) would be some kind of synchronization point, but that doesn't seem to be the case.

I wouldn't have an issue with those changed MSRV requirements if the newly required Rust version were 6 or even 3 months old. But in many cases libraries used brand new features released just a day ago and published those as a patch release. And those weren't actual new Rust language features, but in many cases just syntactic simplifications that would not be required for the code to work.

Maybe there could be some kind of consensus to support stable Rust versions that are at most 6 months old? That would also ensure that the code always builds on Red Hat. But again, this won't work reliably if there's no support in Cargo to enforce that guideline.

I feel that RFC 2495 in combination with LTS releases that are commonly used as MSRV (common synchronization points) is the only way to go in the long run.

7 Likes