Remove the `time = "=0.3.10"` hack once MSRV reaches 1.59

[MaxFangX]

I'd just like to request that the time = "=0.3.10" hack is removed once bitcoind's MSRV reaches 1.59. I have confirmed that the bitcoind build succeeds with time = "0.3" if compiling with version 1.59.

More information

The latest 0.28.1 release which introduced the time = "=0.3.10" hack to support MSRV 1.57 broke our build, which contains serde_with.

Steps to reproduce

cargo new --lib repro-build

Cargo.toml:

[package]
name = "repro-build"
version = "0.1.0"
edition = "2021"

[dependencies]
serde_with = "=2.1.0"
bitcoind = "=0.28.1"

$ cargo build

error: failed to select a version for `time`.
    ... required by package `serde_with v2.1.0`
    ... which satisfies dependency `serde_with = "=2.1.0"` of package `repro-build v0.1.0 (/Users/fang/temp/repro-build)`
versions that meet the requirements `~0.3.11` are: 0.3.17, 0.3.16, 0.3.15, 0.3.14, 0.3.13, 0.3.12, 0.3.11

all possible versions conflict with previously selected packages.

  previously selected package `time v0.3.10`
    ... which satisfies dependency `time = "=0.3.10"` of package `bitcoind v0.28.1`
    ... which satisfies dependency `bitcoind = "=0.28.1"` of package `repro-build v0.1.0 (/Users/fang/temp/repro-build)`

failed to select a version for `time` which could resolve this conflict

Solution

Downgrading our serde_with caused us other problems (specifically, serde_with 2.0.0 is broken), so we had to downgrade bitcoind to 0.28.0 to fix our build. We would like to switch back to the latest version of bitcoind at some point, but to do so requires removing the time = "=0.3.10" hack currently in the Cargo.toml.

Possible workaround to remove the hack while keeping MSRV at 1.57

I spent some time playing around with bitcoind and rust 1.57 and was able to reproduce the 1.57 build problem. Interestingly, after building the crate once with time = "=0.3.10" and generating the Cargo.lock, cargo build still succeeds if you change the dependency back to time = "0.3". If there is a way to specify that time should be version 0.3.10 in the cargo invocation, bitcoind's CI can be fixed, then the hack can be removed, allowing libraries and binaries downstream of bitcoind to avoid this dependency resolution problem. In other words, the CI script seems a better place to put a hack than the Cargo.toml, which has ripple effects on downstream crates.

[Kixunil]

Unless there is an outright bug in cargo this hack can and should be removed immediately. The correct way of pinning dependencies is in Cargo.lock, not Cargo.toml.

[RCasatta]

Yes, it should be removed. PR welcome or I'll do when I get a chance.

There are other issues with MSRV, I am inclined to just raise it since this is a dev dependency we can be less conservative.

[Kixunil]

since this is a dev dependency we can be less conservative.

I think it still makes sense to try to keep it low if possible since people developing libraries with low MSRV ususally want to test them.

[RCasatta]

@MaxFangX have a look at #102 if it solves your issue

[RCasatta]

Closing as commented in #102