serde's -rc4 dependency breaks old cargo #257
Comments
|
One casualty will be Ubuntu 16.04, which has rustc 1.7 and cargo 0.8 in |
This was referenced Jan 31, 2017
Merged
cuviper
added a commit
to cuviper/num
that referenced
this issue
Feb 10, 2017
This bumps the minimum rustc to 1.8.0, "fixing" rust-num#257. I normally consider this a breaking change, but we were already broken due to external factors, for which I couldn't find a workaround. This adds 1.15.0 to the CI matrix to build stable num-derive. We still need nightly to run its tests though, because of compiletest_rs, and dev-dependencies can't be optional. The testing scripts are moved from .travis/ to ci/, as they don't really need to be hidden. It's also now consolidated into one test_full.sh which considers $TRAVIS_BRANCH as needed.
homu
added a commit
that referenced
this issue
Feb 10, 2017
Bump rustc to 1.8 and revamp all CI This bumps the minimum rustc to 1.8.0, "fixing" #257. I normally consider this a breaking change, but we were already broken due to external factors, for which I couldn't find a workaround. This adds 1.15.0 to the CI matrix to build stable num-derive. We still need nightly to run its tests though, because of compiletest_rs, and dev-dependencies can't be optional. The testing scripts are moved from .travis/ to ci/, as they don't really need to be hidden. It's also now consolidated into one test_full.sh which considers $TRAVIS_BRANCH as needed.
cuviper
added a commit
to cuviper/num
that referenced
this issue
Feb 10, 2017
This bumps the minimum rustc to 1.8.0, "fixing" rust-num#257. I normally consider this a breaking change, but we were already broken due to external factors, for which I couldn't find a workaround. This adds 1.15.0 to the CI matrix to build stable num-derive. We still need nightly to run its tests though, because of compiletest_rs, and dev-dependencies can't be optional. The testing scripts are moved from .travis/ to ci/, as they don't really need to be hidden. It's also now consolidated into one test_full.sh which considers $TRAVIS_RUST_VERSION as needed.
homu
added a commit
that referenced
this issue
Feb 10, 2017
Bump rustc to 1.8 and revamp all CI This bumps the minimum rustc to 1.8.0, "fixing" #257. I normally consider this a breaking change, but we were already broken due to external factors, for which I couldn't find a workaround. This adds 1.15.0 to the CI matrix to build stable num-derive. We still need nightly to run its tests though, because of compiletest_rs, and dev-dependencies can't be optional. The testing scripts are moved from .travis/ to ci/, as they don't really need to be hidden. It's also now consolidated into one test_full.sh which considers $TRAVIS_RUST_VERSION as needed.
|
Interesting issue and this seems like the only reasonable move. |
remexre
pushed a commit
to remexre/num
that referenced
this issue
Jun 1, 2017
Fix rust-num#256: support deserializing strings with arbitrary bytes
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See https://users.rust-lang.org/t/crates-io-compatibility-with-old-cargo/9127
It appears that since we have a dependency on serde, even optional, then Cargo < 0.9 (w/ Rust 1.8) can't parse serde-0.9.0's dev-dependency on serde-derive 0.9.0-rc4, specifically the "-rc4" part. It doesn't matter that this version is out of our range, and from my tests even yanking won't solve anything.
So what should num do?
I think we're stuck, because anyone referencing num with old Cargo is seemingly going to have this transitive problem, even if we were to now remove our serde feature entirely. I made a test crate to try this out, and even though the latest version has no dependencies at all, and all others are yanked, it still can't be used by old Cargo.
If somebody has a working Cargo.lock already, they should be fine, hopefully. But for such a person it doesn't matter what we do now. It may be that such old users are extinct by now anyway.
So... shall we embrace the break and raise our minimum Rust to 1.8? That's the least that's not broken right now, through no fault of our own. There are also some nice things we'll gain access to, like the
std::ops::*Assigntraits that were stabilized in 1.8.The text was updated successfully, but these errors were encountered: