Version 2.10.2 release to maintain MSRV

[akern40]

Hello! I recently spent several hours running down why openblas-src had an apparent and sudden MSRV bump despite nothing changing. The culprit is servo/rust-url#937, in which url had a patch change that bumped their MSRV up to 1.67; they have elected not to change this. openblas then fails due to a transitive dependency via ureq. I am wondering whether ureq would be interested in putting a requirement of url < 2.5.1 in your dependencies and releasing a ureq v2.10.2 (branched from v2.10.1). As it stands, ureq does guarantee an MSRV of 1.63 in v2.10.1, which is now violated when a user runs cargo update.

I know this is a much larger ecosystem problem, and if I could I would just patch my crate (ndarray) to use a lower url version; unfortunately, openblas-src is a sort of "indirect dependency" for our crate ndarray in a way that makes patching very difficult.

EDIT: I should note that I would ask openblas directly, except that unlike ureq, they do not guarantee an MSRV.

[algesten]

Alright. Let's do that.

[algesten]

@akern40 i'm with you, in theory. I do want ureq 2.x to be MSRV 1.63, but in practice it's not easy.

I started to try and map down which deps have pulled the rug from underneath us in #878, but there's a lot. Finding the precise versions to lock down is not easy. I've spent a couple of hours on it, and I'm inclined to stop now.

On top of that, people that are not forced to be MSRV 1.63 will not particularly enjoy getting a ureq 2.x update that locks down a ton of dependencies.

I sadly think this is a dead end, but maybe you can convince me otherwise?

[akern40]

@algesten thanks for the quick response! From my own experimentation, it seems like moving the url requirement to url = "<=2.5.0" does the trick? I am drawing this conclusion by cloning ureq, checking out 2.10.1, and running cargo update followed by cargo msrv verify; that gives:

  [Meta]   cargo-msrv 0.16.3
Compatibility Check #1: Rust 1.63.0
  [FAIL]   Is incompatible 
                                                                                                                                                             
  ╭─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
  │ error: package `icu_locid_transform v1.5.0` cannot be built because it requires rustc 1.67 or newer, while the currently active rustc version is 1.63.0 │
  │                                                                                                                                                         │
  ╰─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

I then edit the Cargo.toml to include the locked down url, run cargo update again, and then cargo msrv verify shows

  [Meta]   cargo-msrv 0.16.3
Compatibility Check #1: Rust 1.63.0
  [OK]     Is compatible 

I suppose the question becomes: what counts as MSRV compliant? I think there are two choices:

1. I have specified my direct dependencies to be only those that I know to be MSRV compliant
2. I have specified all dependencies, direct and indirect, to be MSRV compliant

The first one seems achievable, the second one not so much. Let me know if I'm missing something!

[algesten]

@akern40 my checking is by installing 1.63 via rustup and then:

cargo +1.63 build --all-features

Notice all features must be on to see the problem. You can also get that to fail using cargo msrv verify --all-features

[algesten]

We can't maintain MSRV. For 1.63, we need to lock the time crate to =0.3.20, however rustc 1.80 broke all time crates before 0.3.35, meaning we must pick either to bump to our MSRV not be able to compile on rustc newer than 1.79.

Ergo. We are forced to bump MSRV.