Repository navigation
Tracker: rand 0.9 #1165
Description
Activity
We should also conform to common Rust coding standards (generally expected of open projects now). I have argued against these in the past (some poor formatting and false-positive lints, verbosity of opt-outs), but the reasons not to use these are fewer (less active development) and reasons to do so greater (mature tools and very widespread usage):
- use
rustfmt(with#[rustfmt::skip]where required), including CI check - use Clippy (with required opt-outs), including CI check
I suggest only doing this late before v0.9 since both will cause significant merge conflicts and there is currently some on-going work.
- use
We should consider bumping the MSRV to Rust 1.51.0 (March 2021), enabling usage of const generics by default.
Question: do we make a breaking release of
rand_coreat the same time or stick with 0.6.x?See my comment in #1269:
- Avoiding breaking changes to
rand_corelets users upgrade to Rand v0.9 more easily (no need to touch RNGs) - We may well make breaking changes to
RngCorein the future, but likely not soon (most ideas floated depend on unstable language features) - We cannot release 1.0 without
getrandom1.0 - Avoiding breaking changes effectively means we have two MSRVs and corresponding CI tests within the project, but this should be okay
- Avoiding breaking changes to
What breaking changes would we want to release for
rand_core?Possible future changes: #1261, and @newpavlov mentioned somewhere using const generics to re-write
RngCorewith a method likefn generate(&mut self, result: &mut [u8; Self::LENGTH]). (I can't find his comment.)I also would like to rework a bit the crypto traits. We have some issues with them in RustCrypto, see: RustCrypto/traits#1148
Not sure if this would be the place for it, but in terms of major version bumps it'd be good to switch feature specifications over to weak feature dependencies (
"dep?/feature"syntax) once the MSRV >= 1.60. Otherwise there's no actual way to e.g. enablestdwithout also enablingrand_chachaas a dependency cause it'sstd = [.. "rand_chacha/std", ..]Lets go with a breaking release for
rand_coresince we have a few proposed changes and no objections.@coolreader18 feel free to make a PR with your proposed changes after the 1.56 PR is merged. I'm not certain yet we'll use 1.60 but think it's unlikely there will be a significant reason not to.
Is it worth making a release with what we currently have? Selfishly, I'd like to be able to use my PRs, but it's also worth noting that the last release was in February 2022. I tend to prefer the regular release cadence approach rather than the wait for everything to be ready approach. Thoughts?
Reacted by Jeff WidmanI would like to get a release out soon, if only because we've had a lot of changes since the last release. Will have to review (and dedicate a bit of time to this).
Reacted by Alex Saveau and Jeff WidmanUpdate: a pre-release is planned.
I'd like to get a couple more significant changes in before the actual release:
- Remove automatic (delayed) reseed-on-fork #1379
- Switch to
chacha20(@nstilt1), though we shouldn't block release on this - Ideally, Implementing
SliceRandom::choose_multiple(_weighted)is impossible if you aren't simply forwarding the calls to an inner[T]#1307 - Ideally, Upgrade criterion #1329
We should also resolve this, one way or another:
20 remaining items
I marked that whole discussion off-topic (the short version is that we will not be pinning dependencies).
Our MSRV policy is basically just "at least a year old at the time of the next Rand release, and consider other factors". In effect, I decide.
We are open to a PR reducing the MSRV to 1.60, assuming there isn't too much fallout.#1513It may be worth to bump MSRV to 1.63 following the
libcbump: rust-lang/libc#4040Reacted by Diggory Hardyrandv0.9 is now published. Still pending:-
rand_distrv0.5:Poissonvariance deviation at highlambda#1515 (comment) - RNGs: Use rand 0.9.0; fixes rngs#58
-
This is incredibly exciting, thank you!
Blocker:
getrandomv0.3Zerocopy v0.8 — 0.8 Release Roadmap google/zerocopy#671Planned breaking changes for rand 0.9 are:
randuseResult(Error handling of distributions::Uniform::new #1195, API differences between Uniform and Bernoulli #1211)FromSeedtraitRNG rename (likely reject) Rename Rng -> RngExt, RngCore -> Rng #1288SliceRandom::choose_multiple(_weighted)is impossible if you aren't simply forwarding the calls to an inner[T]#1307Rng::gento avoid conflicting with a keyword in Rust 2024 #1435scaleparameter for the uniform float distribution. #1301 or UniformFloat: allow inclusion of high in all cases #1462Possibly also:
Non-breaking TODOs:
Not planned:
Replacing rand_chacha with chacha20 #1348chacha20: returning rand_core feature RustCrypto/stream-ciphers#333