WITHDRAWN: Bump MSRV to 1.57?

[tcharding]

After we do the next release (v0.31.0) should we bump MSRV to Rust 1.57? It becomes two years old in December, which will comfortably be before release v0.32.0.

Rust 1.57 gets us edition 2021 which should reduce the maintenance burden of our current MSRV.

Related

• Target Rust version for crate stabilization #1722 (reply in thread)
• Tracking Issue - MSRV bump (post 1.41.1) #1060

[TheBlueMatt]

How many dependencies do we have that blow up on us? At some point we've pinned them all and there's little new maintenance cost. Last I looked there wasn't much past 1.48 is all that exciting.

[TheBlueMatt]

Mmm, serde is part of the problem, it seems? Another approach is to have a different MSRV for the "base" crate vs the with serde features.

[tcharding]

Thinking through your idea; would this imply that folks concerned about their build chain, presumably the ones using MSRV, do not get access to serde? Is that feasible? Is it meaningful to only guarantee a conservative MSRV for "std" and "no-std" with no other features? This would make introducing usage of crev significantly easier because we could limit the crev'ed dependencies in the same manner.

[tcharding]

We'd have to conditionally include dev dependencies (I forget how but I vaguely remember there is a way). Dependency graphs posted below.

[TheBlueMatt]

We'd still have some MSRV for serde folks, just a different one from more general users.

[apoelstra]

I'm a little hesitant to say "the MSRV is higher if you enable dependencies" when the only breaking changes are in the dependencies themselves, and users can just work around them by pinning. If we were to actually conditionally bump our own MSRV, we could wind up breaking things in our own code without realizing. So we'd start with an MSRV policy that was actually much looser than reality, and initially Debian people wouldn't even notice, and then one day we'd break them and they'd get upset.

As Matt says, at some point we wind up having pinned everything ... and even with all features on we don't have very much to pin. It's basically just serde. (Remember that rand and base64 are both on old major versions, so we don't expect any new changes from them ever.)

[tcharding]

Default "std" build with no other features:

$ cargo tree
bitcoin v0.30.0 (/home/tobin/build/github.com/tcharding/rust-bitcoin/bitcoin)
├── bech32 v0.9.1
├── bitcoin-internals v0.2.0 (/home/tobin/build/github.com/tcharding/rust-bitcoin/internals)
├── bitcoin_hashes v0.12.0 (/home/tobin/build/github.com/tcharding/rust-bitcoin/hashes)
│   ├── bitcoin-internals v0.2.0 (/home/tobin/build/github.com/tcharding/rust-bitcoin/internals)
│   └── hex-conservative v0.1.1
├── hex-conservative v0.1.1
├── hex_lit v0.1.1
└── secp256k1 v0.27.0
    ├── bitcoin_hashes v0.12.0 (/home/tobin/build/github.com/tcharding/rust-bitcoin/hashes) (*)
    └── secp256k1-sys v0.8.1
        [build-dependencies]
        └── cc v1.0.82
            └── libc v0.2.147
[dev-dependencies]
├── bincode v1.3.3
│   └── serde v1.0.183
│       └── serde_derive v1.0.183 (proc-macro)
├── serde_derive v1.0.183 (proc-macro)
├── serde_json v1.0.104
│   ├── itoa v1.0.9
│   ├── ryu v1.0.15
│   └── serde v1.0.183 (*)
└── serde_test v1.0.176
    └── serde v1.0.183 (*)

"no-std" build with no other features

$ cargo tree --no-default-features --features=no-std
bitcoin v0.30.0 (/home/tobin/build/github.com/tcharding/rust-bitcoin/bitcoin)
├── bech32 v0.9.1
├── bitcoin-internals v0.2.0 (/home/tobin/build/github.com/tcharding/rust-bitcoin/internals)
├── bitcoin_hashes v0.12.0 (/home/tobin/build/github.com/tcharding/rust-bitcoin/hashes)
│   ├── bitcoin-internals v0.2.0 (/home/tobin/build/github.com/tcharding/rust-bitcoin/internals)
│   ├── core2 v0.3.3
│   │   └── memchr v2.5.0
│   └── hex-conservative v0.1.1
│       └── core2 v0.3.3 (*)
├── core2 v0.3.3 (*)
├── hex-conservative v0.1.1 (*)
├── hex_lit v0.1.1
└── secp256k1 v0.27.0
    ├── bitcoin_hashes v0.12.0 (/home/tobin/build/github.com/tcharding/rust-bitcoin/hashes) (*)
    └── secp256k1-sys v0.8.1
        [build-dependencies]
        └── cc v1.0.82
            └── libc v0.2.147
[dev-dependencies]
├── bincode v1.3.3
│   └── serde v1.0.183
│       └── serde_derive v1.0.183 (proc-macro)
├── serde_derive v1.0.183 (proc-macro)
├── serde_json v1.0.104
│   ├── itoa v1.0.9
│   ├── ryu v1.0.15
│   └── serde v1.0.183 (*)
└── serde_test v1.0.176
    └── serde v1.0.183 (*)

[apoelstra]

For the default you can see that, outside of dev-dependencies, we depend only on cc (which has only broken MSRV a couple times) and libc (which hasn't ever broken us). With no-std we additionally have core2, memchr, and for same reason hex_lit (which we should get rid of since we have hex-conservative).

So I think the MSRV burden for the "no extra features" case is pretty low.

[nnphuong031]

nice

[junderw]

Out of curiosity:

What kind of tools exist in the ecosystem to find the optimal dependency versions and pins to target a given rust version for MSRV?

I have a personal library that cargo-msrv says only supports 1.66, and I was hoping to get it down to at least 1.63... messing with version requirements was not fruitful. (and it was tedious)...

Not to mention testing each set of features in my library against these MSRV requirements...

Is this a very manual and tedious process? Are there any tips or tricks? Resources with advice in regards to lowering / maintaining MSRV?

[tcharding]

messing with version requirements was not fruitful. (and it was tedious)...

Tell me about it! I do it manually and it is miserable. That is the main reason for raising this discussion :)

[junderw]

For fun (self torture) I tried it with 1.41 toolchain, and I think it had me using a 3 year old tokio or something like that...

I guess some dependencies are just not viable for libraries that care about MSRV... you need to only use libraries that care about MSRV if you want to care about MSRV...

And even then, the dependencies might have a more liberal view of bumping MSRV... some crates view it as a non-breaking change and will break MSRV in patch versions... ugh...

[TheBlueMatt]

FWIW, tokio actually does care about MSRV, just may not always fix it if a dependency of theirs breaks it (but usually its okay, as long as you dont use the macros feature). It supports 1.49 with even the latest LTS.

[tcharding]

Added "WITHDRAWN" to show that this did not get any traction and should not be considered any longer.

[sanket1729]

To get more traction, I do feel that a lot of our time is "wasted" in fixing dependencies for MSRV. I would personally prefer a 2021 version if that fixes our MSRV issues for the foreseeable future.

[apoelstra]

@sanket1729 I think we've had repeated problems with serde_derive and I can't recall a single other problem. (More specifically syn has mostly been giving us grief except for that one time when serde_derive itself started shipping a binary blob. syn is a dependency of serde_derive.)

I think it'd save us 95% of the wasted dep-fixing time to just drop serde_derive. And I'm unconvinced that any finite MSRV would stop the syn pain otherwise.