MSRV bumped without explanation?

[ydirson]

We can see that starting with 4.5.0 the MSRV was raised to 1.74, but there is strictly no information on the reason why, either in the changelog or in the commit message. As user of the crate it feels bad to see the toolchain getting bumped (reduced the ability to get a software backported/included in e.g. Linux distributions), and understanding why this was changed is important.

Digging a bit the commit provides a hint though it does not explain why.

Is any language feature introduced between 1.70 and 1.74 being used?

[epage]

As a maintainer and community member, one of the more draining interactions is "justifying MSRV bumps". For you it may be "i'm curious" but there are enough instances where people "require" a certain level of justification or else "it must be reverted" that just being asked puts me on the defensive and want to react negatively. There is no predictable way for everyone who participates in this thread to walk away satisfied and positive. Each response i can think of opens the door for another point of debate and frustration.

The reason is less important than our policy, which we were acting in, and I'd instead recommend focusing on that. You can search among our closed issues for where the policy is discussed if you'd like to share your precise use case along with the requirements that use case imposes on MSRV and level of support from a dependency.

[epage]

FYI that isn't a "fixed" version but a minimum bound for semver compatible versions. Pinning in Cargo.toml is generally discouraged.

For rebasing, i checkout/restore one lockfile and let cargo take care of the rest. This will be improved with the MSRV aware resolver. You can use a preview of it with cargo +nightly -Zmsrv-policy. You don't generally need to use nightly, only when needing to resolve dependencies.

As for cargo install, it should have told you to use --locked to fix it.

[JosuGZ]

This (clap = { version = "=4.1.3", features = ["derive"] }) seems to fix the problem, thanks.

I think this is a breaking change though, and bumping msrv so often causes problems IMO.

[epage]

Bumping MSRV is generally not considered a breaking change within the ecosystem. Build environment requirements are usually not captured in semver. For example, if we applied build environment requirements to rustc, who knows what version we'd be on for dropping support for older libc, kernels, AndroidNDK, etc.

Bumping major often mostly affects people without lockfiles. Overall, things will improve as we add an MSRV-aware resolver to cargo, see https://rust-lang.github.io/rfcs/3537-msrv-resolver.html

[JosuGZ]

I just ran cargo install gitui --locked and it failed... on clap. Again.

package `clap_builder v4.5.1` cannot be built because it requires rustc 1.74 or newer, while the currently active rustc version is 1.73.0

[epage]

gitui claims their MSRV is 1.70 but they seem to have a problem with actually verifying it, see gitui-org/gitui#2094

[ydirson]

gitui claims their MSRV is 1.70 but they seem to have a problem with actually verifying it, see extrawurst/gitui#2094

Sure, it does not seem unreasonable for MSRV to make claims for a given crate's code - having to take into account (moving) MSRV of dependencies is not a viable option. But then, having dependencies bump MSRVs every so often just makes it impossible to verify the MSRV claim in the end. Only a MSRV-aware dependency handling can help verifying that. But then, what use is specifying a MSRV when you deps make the actual required toolchain a moving version?

Luckily not so many crates have such a narrow-compatibility policy, and it would be greatly appreciated if clap actually would have a larger one.

[epage]

A crate like gitui is not responsible for their dependencies releasing newer versions with a higher MSRV but they need to be able to have a working instance of their dependencies that is compatible with their MSRV so they can verify their MSRV claims and Cargo makes the assumption that packages maintain a set of MSRV compatible dependencies in their Cargo.lock. They acknowledge this in the linked issue: they have a CI that is supposed to verify it but isn't for some reason and they acknowledge this is a problem.