'backtrace' is forcing an increased MinSRV; pin 'backtrace' to `version = "<= 0.3.30"`
rivy opened this issue · comments
'failure' is using backtrace = "0.3.3", which by semantic version auto-upgrade was pulling in 'backtrace' > v0.3.30 (specifically, v0.3.40 most recently). 'backtrace' v0.3.31 introduces use of #[cfg(target_vendor = ...)] which requires rust v1.33.0. So, 'backtrace' is forcing an upgrade of MinSRV to rust v1.33.0 with the change from backtrace v0.3.30 to backtrace v0.3.31.
So, using backtrace > v0.3.30 forces MinSRV to be rust v1.33.0.
Technically, by being less than v1.0.0, 'backtrace' has no semantic version requirement. And there is debate about whether increasing MinSRV is a semantic change. But, in my strong opinion, the surprise disruption of other crate's MinSRV statements downstream is definitely a semantic change.
At the least, I would pin all external crates with version < 1.0.0 to a specific version, hopefully minimizing furture surprise increases in MinSRV.
Usually only binaries should pin a dep to a specific patch. Otherwise if failure pins to =0.3.30 and a different one of my dependencies pins to =0.3.20 then nothing will build.
You should add backtrace = "=0.3.30" to your Cargo.toml and failure will build with that version, since its Cargo.toml is compatible with anything >=0.3.3.
Otherwise if failure pins to =0.3.30 and a different one of my dependencies pins to =0.3.20 then nothing will build.
Which is why its generally better to constrain with the broadest range that works, rather than pin to one version:
backtrace = ">=0.3.3, <0.3.31"If some other dependency requires backtrace ≥ 0.3.31 then its MSRV is also greater than yours, and you would need to constrain that dependency as well, in a similar fashion.
Thanks for the attention and discussion.
I did not know that I could pin a transitive crate version. That's a trick I'll be using immediately in coreutils.
And I do see the merits of pinning a range instead of a specific version, as well. Still though, unless I'm misunderstanding the dependency rules, I think that setting a version range restriction for 'backtrace' here in 'failure' would be a good thing to avoid violating the stated MinSRV.
I would not want a <0.3.31 constraint, that forcibly blocks all downstream crates from using new features of backtrace even if they do not care at all about supporting rustc 1.32 and older. The current dependency specification is accurate because failure works with any backtrace >=0.3.3. In general only binaries should be using <constraints. CI of library code can use cargo update --precise to make version selections on old toolchains.
The msrv discussion has been hashed out many many many times and is not worth having again, it suffices to say that there is not widespread agreement that raising msrv needs a major version after fully considering the tradeoffs.
Longer term, tooling that understands msrv requirements (rust-lang/rust#65262) is the right solution.
As you wish. But since you have an MinSRV statement about 'failure' that is currently incorrect when used without a transitive dependency restraint, shouldn't you update the 'failure' MinSRV to be 1.33.0 now?
Yes, but this crate is not exactly maintained right now. 😉