ureq
ureq copied to clipboard
algesten
MSRV for ureq
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.
Also, we need to feature gate (or get rid of?) the mbedtls example, since it doesn't compile on older rustc.
I found these issues pretty enlightening:
https://github.com/matklad/once_cell/issues/201 https://github.com/rust-lang/libs-team/issues/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."
@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!
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.
FYI, it looks like once_cell is going to be added to the standard library in the near future.
See https://github.com/rust-lang/rust/pull/105587
