unicode-normalization v0.1.10 bumped smallvec to 1, breaking builds with rustc < 1.36

[teythoon]

unicode-normalization v0.1.10 bumped smallvec to 1, breaking builds with rustc < 1.36. This breaks the expectations that an update using the "caret requirements" will still compile. This notably impacts everyone using rustc as packaged by Debian stable.

To recover, please revert the version bump of smallvec, and release 0.1.12. A clean transition to smallvec 1 can be done in 0.2.0.

[Manishearth]

Not all crates guarantee MSRV as part of their stable API. Please pin the dependency if you need to .

cd63ded

[nox]

I feel like unicode crates are quite important and should guarantee MSRV. Is this up for discussion?

[nox]

Oh, it has been discussed already, ok.

[Manishearth]

The more important the crate is the more churn a breaking change causes. It's a two edged sword, guaranteeing MSRV is not an obvious choice.

[teythoon]

Please pin the dependency if you need to.

Thanks for the hint, I will do that for future releases.

However, I cannot do that for past releases. Because we depend on a library that is not installed in the docs.rs build environment, we do build and host our documentation ourselves. So now to build the documentation for every release we made so far, our solution has to cargo update -p unicode-normalization --precise 0.1.9 to build the documentation.

So yeah, we can handle that, but it is a hassle.

[mbrubeck]

Alternately you could include a Cargo.lock file in your library repo. I know the official docs say this is not useful for libraries, but in specific cases, like pinning to old Rust toolchains and corresponding dependencies, it is very useful.

[kinnison]

While it's hard to manage MSRV, it'd be valuable for crates as potentially core as this one to try their best to not require beyond 1.34.2 without a breaking change in their semver. Debian (and potentially other OSes derived from it) ship 1.34.2 in their stable release currently and yes it's a difficult job but maintaining buildability on that platform is valuable for our users. This is actually a core part of my inclusivity message for Rust 2020.

[teythoon]

Alternately you could include a Cargo.lock file in your library repo.

We do have the Cargo.lock checked in, and this doesn't seem to help.

Edit: Thinking more about this, I think you are right, this should and probably does help. However, our early releases do not contain the Cargo.lock. Which brings me back to my original problem: What should I do about prior releases?

[Manishearth]

@kinnison the problem is, ultimately, doing breaking changes on MSRV requires everyone else in the ecosystem to do piecewise upgrades, when it comes to core crates like this one. it's a tradeoff, and i rarely see the other side of that tradeoff acknowledged. It's a lot of work, and I'd be happy to make this a major semver bump and yank the old version if someone was willing to put in the effort of getting all of these crates (and their reverse dependencies, etc) upgraded. I cover this a bit here. Ultimately, I'm not interested in doing a ton of labor to support this use case, when there are workarounds available for people with this use case.

@teythoon which library is this? cargo update -p unicode-normalization --precise 0.1.9 might help.