Skip to content

Conversation

@baloo
Copy link
Contributor

@baloo baloo commented Dec 24, 2025

Summary

Not binding to a strict version of chacha20 (only a minimum) would make for a much smoother release process. Especially to get over the API breaks humps coming in rand_core 0.10.0-rc.3

Motivation

Details

Not binding to a strict version of chacha20 (only a minimum) would 
make for a much smoother release process. Especially to get over the API
breaks humps coming in rand_core 0.10.0-rc.3
@dhardy
Copy link
Member

dhardy commented Dec 24, 2025

Not strictly restricting the patch-version of rand_core v0.10.0-rc-2 is why CI is currently broken. Semver allows breaking changes in any pre-release version.

@dhardy dhardy closed this Dec 24, 2025
@baloo
Copy link
Contributor Author

baloo commented Dec 24, 2025

Please commit the cargo.lock then. This is what it is used for.

Restricting the version in the cargo.toml makes it hard (requires a patch on top, and a git branch, more work) to test changes in downstream crates.

I’m doing integration work in large consumers of the rustcrypto ecosystem (tss-esapi, rpgp, …) that proved to be helpful chasing down bugs early in release cycle. Having to unpin version for every dependency would be a lot more work than it currently is.

@dhardy
Copy link
Member

dhardy commented Dec 24, 2025

Restricting the version in the cargo.toml makes it hard (requires a patch on top, and a git branch, more work) to test changes in downstream crates.

What I don't understand here: you want to use rand with a downstream crate and the new rand_core 0.10.0-rc.3; this requires a patch to rand regardless of the version dependency here (until #1697 is merged).

Hence, this only benefits cases where pre-releases are not API-breaking (or at least not affecting some dependency) IIUC?

I can see some benefit then, but it's not as simple as this PR; it also requires committing Cargo.lock as @tarcieri mentioned. I suppose we can do that, but please open a new PR and write a good motivation section. The tests likely also want tweaking (update instead of generate-lockfile maybe?).

We ought to merge #1697 first. In any case, I'm off now for a few days; happy Christmas (if relevant to you).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants