Suggest MSRV policy

[matklad]

I don't think there's a strong consensus here yet.

However, there seems to be a weak consensus, and also de-facto
practice for many popular crates (cfg-if, lazy-static).
Additionally, there's a lot of continuous discussion and re-litigation
across various forums and issue trackers.

So it seems like tentatively documenting current practice might make sense?

[matklad]

cc @BurntSushi

[BurntSushi]

I agree with this recommendation and routinely advocate it. However, I worry about elevating it to the API guidelines because there are some prominent crates that treat an MSRV increase as a semver breaking change. I think the crossbeam and rayon projects do this, for example, and IIRC there are some crypto crates that do as well. (base64 might as well. In practice they do, anyway, but I've never seen their policy clear stated.)

One possible compromise would be to mention that there are some crates that treat MSRV bumps as a semver breaking change, but that the library team does not recommend it.

It would be nice to do an FCP for the library team, but I'm not sure if this repo is hooked up to that. Instead I'll just ping library team members: @Amanieu @KodrAus @dtolnay @sfackler @withoutboats

For me personally, I'd be in favor of this. I think treating MSRV bumps as a semver breaking change is largely impractical. Or more specifically, the advantages of treating MSRV bumps as semver breaking changes do not outweigh the disadvantages. More practically, a number of core crates don't treat MSRV bumps as semver breaking changes, which makes practicing that policy rather difficult in reality anyway.

[matklad]

Added a wording that bumping major is not wrong.

I think the crossbeam and rayon projects do this, for example

It's interesting that rayon didn't do a major bump when upgrading crossbeam to a new major recently: rayon-rs/rayon#807. For those bumping into this issue, this is actually a good example for why not bumping major might be a good idea: now the latest rayon is only compatible with 1.36. If crossbeam published a semver compatible release, new rayon could still be usable with 1.31 (with sutably crafted Cargo.lock, pining crossbeam to an older version).

[lunacookies]

Sorry, I really should have done that as one review, instead of individual comments. I’ve never done code review on GitHub before, so please excuse my mistake :)

[jyn514]

This is actually the first good usecase I've seen for RUSTC_BOOTSTRAP.

Suggested change

	To reliably test MSRV on CI, use a dedicated `Cargo.lock` file with dependencies
	pinned to minimal versions:
	```bash
	$ cp ci/Cargo.lock.min ./Cargo.lock
	$ cargo +$MSRV test
	To reliably test MSRV on CI, use `-Z minimal-versions`:
	```bash
	$ RUSTC_BOOTSTRAP=1 cargo +MSRV -Z minimal-versions test
	```

That said, maybe it's not a good idea to recommend it so prominently - it might be possible to find the equivalent nightly but it sounds annoying to do.

https://doc.rust-lang.org/cargo/reference/unstable.html#minimal-versions

[taiki-e]

I definitely do not recommend using RUSTC_BOOTSTRAP + -Z minimal-versions:

• -Z minimal-versions is added in cargo 1.27. It does not work on older versions. (rust-lang/cargo@9a09892)
• If dependencies are incompatible with -Z minimal-versions, compile will fail for reasons unrelated to MSRV.
• It is an unstable feature, so may be changed in the future.

(Note that dev-dependencies may raise version requirements, so running test with -Z minimal-versions may not work properly for its intended purpose. Ideally, it needs to run cargo update -Z minimal-versions after completely remove the dev-dependencies. See tokio-rs/tokio#3131 (comment) for more.)

[matklad]

Yeah, I concur that manually updating Cargo.lock.min at this moment is likely to require less maintenance. But -Z minimal-versions is clearly an interesting alternative, I bet someone will learn about it from this comment!

[KodrAus]

Thanks everyone for participating so far! We're currently trying to wrangle the API Guidelines project a bit by shifting discussion towards GitHub's discussions feature where possible and reserve PRs for guidelines that have been generally accepted already. This hasn't been communicated at all yet so sorry everyone for jumbling things around here 🙇

I've opened #231 to continue the discussion on MSRVs and will close this one for now.