Allow use of wasip3 0.3 for MSRV reasons.#824
Conversation
newpavlov
left a comment
newpavlov
left a comment
There was a problem hiding this comment.
Interesting. I haven't thought about using >=0.3, <=0.4-like bounds in such fashion.
| # Projects that need to support MSRV 1.85 can use the following: | ||
| # ``` | ||
| # CARGO_RESOLVER_INCOMPATIBLE_RUST_VERSIONS=fallback cargo update -p getrandom | ||
| # ``` |
There was a problem hiding this comment.
I think it's better to put this instruction into changelog since it would more visible.
Also, is this command necessary? I thought that the MSRV-aware resolver should generate 1.85-compatible Cargo.lock automatically for a project with rust-version set to 1.85.
There was a problem hiding this comment.
Also, is this command necessary? I thought that the MSRV-aware resolver should generate 1.85-compatible Cargo.lock automatically for a project with rust-version set to 1.85.
It depends on if they use Edition: 2024 or not, I think.
There was a problem hiding this comment.
...and also what their .cargo/config.toml has.
There was a problem hiding this comment.
I think that in practice almost all project which use MSRV 1.85+ have been updated to the latest edition, so we probably can ignore such scenarios.
There was a problem hiding this comment.
I think it's better to put this instruction into changelog since it would more visible.
I moved it in the README where the MSRV documentation is. And I added a CHANGELOG.md entry.
There was a problem hiding this comment.
I think that in practice almost all project which use MSRV 1.85+ have been updated to the latest edition, so we probably can ignore such scenarios.
- The project itself might not have MSRV 1.85 (on every target it supports)
- The default can be overridden in .cargo/config.toml, I think. The command I provide works regardless of what the default mode is.
There was a problem hiding this comment.
In my opinion crate documentation is not a good place for instructions on how to deal with the MSRV-aware resolver. We have language/Cargo docs for that. But let's keep it for now.
There was a problem hiding this comment.
I agree but on the other hand the MSRV documentation also does need to indicate that there is some nuance to the documented MSRV.
This allows a project dependeing on `getrandom` to use this to get an Fully Rust-1.85-compatible Cargo.lock, while still allowing projects with newer MSRV to use 0.4: ``` CARGO_RESOLVER_INCOMPATIBLE_RUST_VERSIONS=fallback cargo update -p getrandom ``` Inspired by the windows-sys documentation that recommends using the same pattern.
getrandom 0.4.2 seems to have implemented good enough support with its wasm_js feature to make it usable as an alternative to getrandom 0.2. Rust 1.84 (and getrandom 0.3) dropped support for the old wasm32-wasi target, and won't build for that target, so stop supporting it. Deal with MSRV. See rust-random/getrandom#824.
getrandom 0.4.2 seems to have implemented good enough support with its wasm_js feature to make it usable as an alternative to getrandom 0.2. Rust 1.84 (and getrandom 0.3) dropped support for the old wasm32-wasi target, and won't build for that target, so stop supporting it. Deal with MSRV. See rust-random/getrandom#824.
getrandom 0.4.2 seems to have implemented good enough support with its wasm_js feature to make it usable as an alternative to getrandom 0.2. Rust 1.84 (and getrandom 0.3) dropped support for the old wasm32-wasi target, and won't build for that target, so stop supporting it. Deal with MSRV. See rust-random/getrandom#824.
2 participants
This allows a project dependeing on
getrandomto use this to get an Fully Rust-1.85-compatible Cargo.lock, while still allowing projects with newer MSRV to use 0.4:Inspired by the windows-sys documentation that recommends using the same pattern.