-
Notifications
You must be signed in to change notification settings - Fork 471
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bump MSRV to Rust 1.38 #877
Conversation
dc70a29
to
6ac1232
Compare
FYI @cuviper (because this PR affects rayon's MSRV) Also, aside from this PR, I would like to update our MSRV policy to support 1 year instead of 6 months. Otherwise, it is impossible for rayon to actually maintain their MSRV policy (because our current MSRV policy allows us to increase the MSRV as a minor change). |
bors r+ |
Build succeeded: |
880: Prepare for the next release r=taiki-e a=taiki-e - crossbeam-channel 0.5.5 -> 0.5.6 - Bump the minimum supported Rust version to 1.38. (#877) - crossbeam-deque 0.8.1 -> 0.8.2 - Bump the minimum supported Rust version to 1.38. (#877) - crossbeam-epoch 0.9.9 -> 0.9.10 - Bump the minimum supported Rust version to 1.38. (#877) - Mitigate the risk of segmentation faults in buggy downstream implementations. (#879) - Add `{Atomic, Shared}::try_into_owned` (#701) - crossbeam-queue 0.3.5 -> 0.3.6 - Bump the minimum supported Rust version to 1.38. (#877) - crossbeam-utils 0.8.10 -> 0.8.11 - Bump the minimum supported Rust version to 1.38. (#877) - crossbeam 0.8.1 -> 0.8.2 - Bump the minimum supported Rust version to 1.38. (#877) Co-authored-by: Taiki Endo <te316e89@gmail.com>
Thanks for the heads-up. I have no problem with this tiny bump. 🙂 FWIW, I'm looking at 1.56 in rayon-rs/rayon#964, but that will wait a few months yet to meet our 1-year MSRV policy. |
FYI this has broken rand's CI (using Rust 1.36). It's not critical since it's only through |
We had treated MSRV bump as a major change in the past, but maintaining that policy was a pain for both maintainers and users, so we changed our policy. See #444 (comment) and #503 (comment) for more. (FYI, rust-lang/libc#2845 and rust-lang/libs-team#72 are the latest discussions on MSRV for crate widely used in the ecosystem. )
FWIW, AFAIK, dev-deps often have much more lenient MSRV policy than the crate under test, so there are many projects that do not run |
Committing only to support rustc versions no more than 6 months or 1 year old honestly sounds like a sensible option to me. We've seen very little concern about bumping the MSRV of rand in the past.
Sorry, I shouldn't complain about something already using the best apparent solution! |
Just FYI. I am not sure if this is the best way, but instead of bumping the MSRV of my library, I have been working around it by pinning dependencies to some older versions in moka-rs/moka/blob/78050701a/.github/workflows/CI.yml#L55-L67 - name: Pin some dependencies to specific versions (MSRV only)
if: ${{ matrix.rust == '1.51.0' }}
# hashbrown >= v0.12 requires Rust 2021 edition.
# native-tls >= v0.2.9 requires more recent Rust version.
# async-global-executor >= 2.1 requires Rust 2021 edition.
# pull-down-cmark >= 0.9.2 requires Rust 2021 edition.
run: |
cargo update -p dashmap --precise 5.2.0
cargo update -p indexmap --precise 1.8.2
cargo update -p hashbrown --precise 0.11.2
cargo update -p native-tls --precise 0.2.8
cargo update -p async-global-executor --precise 2.0.4
cargo update -p pulldown-cmark --precise 0.9.1 |
913: Remove dependency on once_cell and work around windows-gnu LTO issue r=taiki-e a=taiki-e Replace `once_cell` with our own `OnceLock` that based on unstable `std::sync::OnceLock` due to MSRV issue[^1]. This also fixes #856 due to windows-gnu LTO issue. [^1]: [The current readme says crossbeam support at least 6 months old compilers](https://github.com/crossbeam-rs/crossbeam/blob/e54f01e7a7e3913407e817ce3e578a76b6392ef1/README.md#compatibility), but that is a minimum guarantee and is [actually more conservative](#877 (comment)). Co-authored-by: Taiki Endo <te316e89@gmail.com>
It was released nearly 3 years ago and meets our MSRV policy.
This allows using const_in_array_repeat_expressions (rust-lang/rust#49147) and
<pointer>.cast()
.