MSRV bump 1.67 in v2.5.1

[tnull]

The most recent patch release v2.5.1 bumped the MSRV from 1.56 to 1.67. Unfortunately, this violates a whole chain of downstream projects with a lower MSRV, e.g., reqwest (cc @seanmonstar) and dependents.

Especially since this happened in a patch release, CIs are now failing everywhere down the chain and projects that can't or are not willing to bump their MSRV are now forced to find some kind of workaround.

It would therefore be great if you could reconsider that bump and, e.g., would consider introducing the corresponding changes (I believe in #923) behind a feature (preferably defaulting to off) so that any downstream projects can actually choose whether they are willing or able to support 1.67 as their MSRV.

[Manishearth]

Not going to express a strong opinion on whether rust-url should have updated MSRV, in general for crates near the bottom of lots of deptrees I prefer extreme conservatism for MSRV but it really depends on the project.

In general I do disagree with "changing MSRV is breaking. Fixing it is a cargo update away for end-clients, and Cargo already has functionality for doing msrv-aware dep resolution that you should try using in CI. "CI breaks" is not necessarily a sign of breakage, it can just be a signal of change that you should be aware of.

....However it definitely is nice to avoid the situation where possible and provide mitigations if necessary. Would be nice to explore options.

[TheBlueMatt]

Cargo already has functionality for doing msrv-aware dep resolution that you should try using in CI

Sadly, this is only available for relatively new cargos, making it useless for fixing MSRV breaks for those supporting conservative MSRVs :(. Another year or two and it'll become useful.

[Manishearth]

FWIW I have held the position "changing MSRV is breaking unless explicitly a part of the contract" for long before that feature existed:

• End users can cargo update. This is far less work than how some other kinds of allowed-in-Rust-but-will-fail-to-compile breakages are mitigated (technically any time you add a new item to your crate you risk breaking people using glob imports)
• It's fine if CI breaks. CI breaking doesn't impact end users. You can tweak the CI to run cargo update or something.

but still, I'd say we should attempt some mitigation here. url is pretty deep in a lot of deptrees

[valenting]

@Manishearth how would such a mitigation work? I don't think we can put the idna changes behind a feature flag.
Would backing out the changes and releasing 2.5.2 work, then we release 2.6.0 with a bumped MSRV?

[epage]

The Cargo semver guidelines recommend treating MSRV as a minor incompatibility, and not a major incompatibility. This could mean bumping minor but we should also keep in mind that, for semver and Cargo, there is almost no distinction between minor and patch. The main reason to bump minor instead of patch is to give flexibility to backport fixes to the pre-MSRV bump version.

Also, the MSRV-aware resolver is not stable yet. It is available on nightly. Whether stable or nightly, using it does not require an MSRV bump. I have been using it myself to help manage my MSRV (like when I dropped the MSRV of my packages back to 1.65).

MSRV testing in CI is aided by checking in your lockfile.

[epage]

but still, I'd say we should attempt some mitigation here. url is pretty deep in a lot of deptrees

imo MSRV should be requirements driven. I have not heard of a requirement older than Debian stable which is 1.63. Even that requirement is a bit dubious as we generally view the Debian toolchain as intended for building Debian packages and not intended for end users. 1.67 is over 10 versions behind and is a year and a half old.

how would such a mitigation work?

Is the bump purely from dependencies? Can you drop the version requirements on the icu4x dependencies? For example, dropping to icu_normalizer@1.3.0 will get it down to 1.66. Unfortunately, icu4x only recently started tracking their MSRV so going further down from that would be guess and check. Looks like icu4x's MSRV policy is 4-6 versions. You can have a lower MSRV so long as their lowest MSRV is compatible with yours and you are fine not being able to require the latest features. This could mean delaying this feature completely until the lowest MSRV from icu4x works for you. There is the question of whether icu4x would be willing to lower their MSRV. That would be a question of what all they are using from newer versions and how well they can be mitigated.

[tnull]

imo MSRV should be requirements driven. I have not heard of a requirement older than Debian stable which is 1.63. Even that requirement is a bit dubious as we generally view the Debian toolchain as intended for building Debian packages and not intended for end users.

Could you clarify who is 'we' and and how you come to that conclusion? Supporting Debian stable seems like a hard requirement for quite a few users, and given that it's not even two years old rustc 1.63 seems like a reasonable MSRV target that (in my experience) a large part of the Rust ecosystem seem to be able to get behind.

[TheBlueMatt]

we generally view the Debian toolchain as intended for building Debian packages and not intended for end users

This seems like a weird conclusion. Until Fedora 34, the Debian toolchain was the only way to accomplish cross-language LTO without building both clang/LLVM and rustc from source. Thus, its in fact the only option for a toolchain that can be used in some build systems. For projects building multi-language systems which want X-lang LTO and want people to be able to build the software themselves, not supporting Debian's stable toolchain is not an option.

[Manishearth]

Could you clarify who is 'we' and and how you come to that conclusion?

I believe Ed is talking for the Cargo team here? (That's what I read those comments as)

Supporting Debian stable seems like a hard requirement for quite a few users, and given that it's not even two years old rustc 1.63 seems like a reasonable MSRV target that (in my experience) a large part of the Rust ecosystem seem to be able to get behind.

I do not think the comment was suggesting that Debian stable should not be supported, it was saying that it's unclear if crates need to strictly follow such an MSRV to support the needs of Debian stable. (Debian does not need to pull in the latest version of this crate, and other mitigations are also possible).

---

@valenting

how would such a mitigation work? I don't think we can put the idna changes behind a feature flag. Would backing out the changes and releasing 2.5.2 work, then we release 2.6.0 with a bumped MSRV?

I was hoping there was a way to keep the old code around as fallback. But there may be other ways.

Switching from patch to minor release would not really change the effects this has on users but it would be slightly clearer at least.

[epage]

Yes, I was speaking to a general feel I've gotten from Cargo team discussions. And it was not to be prescriptive (ie not "you shouldn't) but to provide insight when people determine what requirements drive their MSRV policy (ie "should you?").

[epage]

I was hoping there was a way to keep the old code around as fallback. But there may be other ways.

Sounds like this was a fairly invasive change so my idea might not work. What I've been experimenting with recently is to delegate the MSRV-dependent code to a dependency. You have two versions, one for the old MSRV and one for the new. They should have compatible APIs and I number the versions for what their MSRV is. The main drawback is that you can't declare through version requirements that you need new versions of each minor release so the API should likely be frozen.

example: https://crates.io/crates/is_terminal_polyfill/versions