Dependency stability: Release candidate dependencies causing frequent downstream breakages

[BiagioFesta]

Hi,

First, thank you for your work on this library. I wanted to bring attention to a recurring issue we're experiencing with the current dependency specifications.

Current Situation

The library currently pins several dependencies to specific release candidate versions:

block-buffer = "=0.11.0-rc.5"
crypto-common = "=0.2.0-rc.4"
pkcs1 = "=0.8.0-rc.4"
pkcs8 = "=0.11.0-rc.7"
der = "=0.8.0-rc.9"
# ...

Problem

These release candidate dependencies are causing frequent downstream breakages as they receive updates (roughly monthly). For example, picky crate is currently failing to compile with errors like:

 error[E0277]: the trait bound `R: crypto_bigint::rand_core::RngCore` is not satisfied
   --> crypto-primes-0.7.0-pre.4/src/hazmat/miller_rabin.rs:132:36
    |
132 |         let random = T::random_mod(rng, &range_nonzero)
    |                      ------------- ^^^ the trait `DerefMut` is not implemented for `R`

Impact

While I understand this library is at version 0.18.1 and technically not promising API stability, Rust's cargo ecosystem typically maintains compatibility even for 0.x versions. These RC dependency breaks are causing unexpected build failures for downstream users.

---

Would it make sense to make this library itself a release candidate (with -rc suffix) if it needs to depend on RC versions of other libraries? This would better signal to downstream users the potential for instability, and if there's a specific reason for needing these RC dependencies, it could be documented in the Cargo.toml.

Thank you

[CBenoit]

I’m sorry for the inconvenience with that recently. The current status quo is definitely not okay, and we’re trying to to mitigate that actively.

Would it make sense to make this library itself a release candidate (with -rc suffix) if it needs to depend on RC versions of other libraries? This would better signal to downstream users the potential for instability, and if there's a specific reason for needing these RC dependencies, it could be documented in the Cargo.toml.

Making the -rc suffix propagate would be a much better approach indeed. If this happen again in the future we’ll do that.

[BiagioFesta]

Thank you

Not sure if useful, but if you really need to dep on RCs, another suggestion might be to grep all rc dependencies cargo tree | grep "-rc" and pin them all

[CBenoit]

Good suggestion. We’ll release a hotfix using this approach as a stopgap. I’ll yank the other releases.