At the current time, I don't think there is a strong consensus. However, I do believe there are some plans for the path forward. IIRC, they sprung out of the post-poned RFC for LTS releases and a different RFC addressing minimum supported Rust specifically. @aturon then outlined some ideas for moving forward here: http://aturon.github.io/2018/07/25/cargo-version-selection/
If I had to guess at the pulse, I think I'd say that our current trajectory is towards a solution that involves Cargo becoming aware of the minimum supported Rust version, but I don't have any good feeling of how strong that trajectory is.
In terms of practice, this is what I currently do:
- For crates that I maintain that are 1.0 or greater, I do my best to be conservative with the minimum supported Rust version. However, I specify a policy that permits bumping the minimum supported Rust version in minor version releases. So a 1.1 release could require a newer Rust than a 1.0 release. This is somewhat of a compromise, and I'm not sure it's a very good one either. Example: https://github.com/rust-lang/regex#minimum-rust-version-policy
- For crates at 0.x, I also try to do a minor version release when bumping the minimum Rust version. In this case, it's a semver bump as opposed to the aforementioned strategy for 1.0 crates which is not a semver bump.
- For applications, I've switched to "requires the latest stable release of Rust, but all patch releases will compile on the same version of Rust that its corresponding minor version compiled on." I tried to be more conservative about this for a while and even succeeded, but once I switched to crossbeam-channel, ripgrep grew a whole new mess of dependencies that made it completely intractable for me to stay on top of this. So I gave up after consulting interested parties: https://github.com/BurntSushi/ripgrep/issues/1019
I do not think the current situation is sustainable. Even though I specifically watch for stuff like this in most of my dependencies, I still miss things. The only way it's going to get fixed IMO is either with a very strong community rallying point (LTS releases or @aturon's "shared policy") or with tooling (@aturon's "stated toolchain"). In particular, many of the more widely used crates that I maintain are quite conservative and aren't seeing major internal changes, so there's really no strong impetus to use new language features. On occasion, new features come along that I want to use, I've ended up achieving that via version sniffing and conditional compilation. It's not ideal and certainly cannot be achieved in every case. For crates that are moving more quickly or want to take advantage of new language features, a conservative MSRV policy is probably quite annoying and/or difficult to adhere to.