You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
But using rust-version instead with releases, as it minimizes the MSRV concern by minimizing effort to create a compatible lockfile.
Describe the solution you'd like
Adopt rust-version in Cargo.toml.
It'll display the minimum supported Rust version on crates.io versions tab for Warp.
Tools like cargo-upgrade, cargo add and cargo +nightly update -Z msrv-policy can leverage this information to better resolve a release in semver that is compatible.
Describe alternatives you've considered
Version pinning in Cargo.toml or manually managing pinning with Cargo.lock generation.
Additional context
-Z msrv-policy minimizes the effort when crates properly publish and maintain declared rust-version, minimizing the issue of semver resolving point releases with MSRV bumps.
When an MSRV is not known, you can usually get away with cargo-msrv command on your crate to detect the lowest version that is compatible, then add that as the rust-version. Whenever that would become incompatible, just bump it up again with the next release, no worries 👍
rust-version is just a guidance of what should be possible to build the crate with. Sometimes like with hashbrown 0.14.2 this may require pinning some dependencies. It does not need to be raised when dependencies bump the MSRV implicitly, if they adopt rust-version too and update it correctly the whole issue is avoided.
rust-version only needs to be updated when you explicitly introduce changes into the project that would require a newer version of rust to build. It's important to try keep that accurate, otherwise the resolver advantage from rust-version becomes less useful (recent example with tokio-util).
The text was updated successfully, but these errors were encountered:
You also manage reqwest where MSRV was raised to 1.63 due to tokio, but the dependency in reqwest is tokio = "1", thus that is not exactly accurate for rust-version, and could possibly have been kept lower.
reqwest can have an MSRV policy AFAIK that would only support users with Rust on 1.63, but the rust-version bump is a bit inaccurate unless you're using a feature from tokio that actually required building with at least Rust 1.63, and could not resolve an earlier release of tokio where it'd have been compatible on earlier Rust toolchains.
Since tokio already adopts rust-version, you could more easily verify that in CI with cargo +nightly update -Z msrv-policy, which for example would fail cargo +version_here check --tests if any dependencies for reqwest did not resolve. There is the occasional hiccup as linked earlier with tokio-util, which would either require you to raise your own rust-version or manage a Cargo.lock.
Ideally you only need to bump rust-version when a change like tokio-util 0.7.9 introduced required it, or updating a dependency that raised it's own rust-version where -Z msrv-policy may not be sufficient (eg: upgrading hashbrown to newer minor release bump like hashbrown 0.14).
Is your feature request related to a problem? Please describe.
Similar to #948
But using
rust-version
instead with releases, as it minimizes the MSRV concern by minimizing effort to create a compatible lockfile.Describe the solution you'd like
Adopt
rust-version
inCargo.toml
.crates.io
versions tab for Warp.cargo-upgrade
,cargo add
andcargo +nightly update -Z msrv-policy
can leverage this information to better resolve a release in semver that is compatible.Describe alternatives you've considered
Version pinning in
Cargo.toml
or manually managing pinning withCargo.lock
generation.Additional context
-Z msrv-policy
minimizes the effort when crates properly publish and maintain declaredrust-version
, minimizing the issue of semver resolving point releases with MSRV bumps.When an MSRV is not known, you can usually get away with
cargo-msrv
command on your crate to detect the lowest version that is compatible, then add that as therust-version
. Whenever that would become incompatible, just bump it up again with the next release, no worries 👍rust-version
is just a guidance of what should be possible to build the crate with. Sometimes like withhashbrown 0.14.2
this may require pinning some dependencies. It does not need to be raised when dependencies bump the MSRV implicitly, if they adoptrust-version
too and update it correctly the whole issue is avoided.rust-version
only needs to be updated when you explicitly introduce changes into the project that would require a newer version of rust to build. It's important to try keep that accurate, otherwise the resolver advantage fromrust-version
becomes less useful (recent example withtokio-util
).The text was updated successfully, but these errors were encountered: