MSRV for ureq

[algesten]

We haven't got an explicit MSRV, just "be conservative", but it probably is time to put one in place. once_cell has bumped their MSRV to 1.56 (and edition 2021), which is a pretty huge jump for us.

De-facto our MSRV is 1.53 because of our close dependency on rustls. Since once_cell is less central to ureq than rustls, I propose we try to get rid of the once_cell dependency (maybe go back to lazy_static?) and stay aligned with rustls.

I also propose we stay with edition 2018, for now.

[algesten]

Also, we need to feature gate (or get rid of?) the mbedtls example, since it doesn't compile on older rustc.

[jsha]

I found these issues pretty enlightening:

matklad/once_cell#201
rust-lang/libs-team#72

In short, since once_cell intentionally chose a semver minor release, it is still possible for ureq to support Rust versions older than 1.56. It is just up to the end-user application to pin once_cell to 1.14.0 in Cargo.lock. Since we just say once_cell = "1", that will resolve just fine. Now, it's a little hard in general for the end-user to pick such versions, but we can document this - "To build with Rust older than X, you will probably need to edit your Cargo.lock. In particular you will need to set once_cell to 1.14.0. You may need to do the same with other crates."

[algesten]

@jsha yes. I have read (and am following these issues).

Generally I don't agree with the positions those threads have arrived. For "foundational crates" (for lack of a better term), like libc and once_cell, I would have hoped for a far more conservative MSRV than ~1 year back. Mainly it's selfish reasons – I'm so old that 1 year goes by very fast and I have funner things to do than keeping my dev env fresh and/or editing old Cargo.lock-files for software I've once written and want to compile again.

Ureq obviously doesn't have much usage compared to those crates, but I think we can lead by example and not subject our users to the pains of ~1 year MSRV unless we're forced to.

Getting rid of once_cell seems like a small price to pay… and maybe we can even reduce deps!

[jsha]

I think we cannot actually get rid of once_cell. We depend on it transitively via ring.

I suspect our MSRV stance will mostly be dominated by that of our downstream dependendencies, and those decisions are being hashed out now. IMO we can afford to take a wait and see approach before committing to an MSRV policy ourselves.

[rmg-x]

FYI, it looks like once_cell is going to be added to the standard library in the near future.

See rust-lang/rust#105587

[algesten]

Related to #712

[algesten]

Time to add a CI test for this. Clearly.