-
Notifications
You must be signed in to change notification settings - Fork 430
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracker: rand 0.9 #1165
Comments
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):
I suggest only doing this late before v0.9 since both will cause significant merge conflicts and there is currently some on-going work. |
Fixing the clippy warnings is not a big deal, we are already doing pretty well. Also see #1197. |
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 See my comment in #1269:
|
What breaking changes would we want to release for |
Possible future changes: #1261, and @newpavlov mentioned somewhere using const generics to re-write |
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 ( |
I guess we could go all the way to 1.60 (April 2022). We already have a PR for 1.56: #1269. |
Lets go with a breaking release for @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? |
I 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). |
Update: a pre-release is planned. I'd like to get a couple more significant changes in before the actual release:
|
We should also resolve this, one way or another: |
I don't think #1399 is a blocker, it's one of the caveats of using |
Fair point, although we already have value-breaking changes here.
|
We are looking at updating the The simplest way to implement this is to use CC: @newpavlov |
At the rate we're going, that may still be a year old by the time 0.9 is ready (though I hope not). I am not aware of any hard constraints here. |
Is there a reason you can't use zerocopy 0.7.32? What 0.8 features do you need? Maybe we could backport things to 0.7 to unblock you? |
Update: I've submitted #1446; at least as of the current state of |
We've merged RustCrypto/stream-ciphers#333 which re-adds However, it will probably still be some time before we cut a release, and one of the potential blockers on such a release is if we should upgrade to a prospective |
It sounds like numpy allows returning the exclusive bound of a range, so doing #1462 seems reasonable especially since it probably improves performance. |
@dhardy, sorry for disappearing for so long. I can take another look at the uniform changes this weekend (probably Sunday), but don't wait for me if you want to get the release out sooner! |
Our to-do list is now done (excepting replacing ChaCha code with the One last thing I'd like to solve, however, is I'm away on holiday from Thursday and would love to make a beta release of v0.9 before then. |
I have published an alpha: https://github.com/rust-random/rand/tree/0.9.0-alpha.2 (master + #1471 + #1480 + a couple of tweaks to |
Can https://github.com/rust-random/rngs get alpha releases too? Pretty sure it's not possible to upgrade if use something like |
Create MSRV policy and hardcode dependencies, otherwise you can lose MSRV if dependency upgrades its MSRV in minor version. I am happy with any MSRV <= 1.60. Usually 1.56.0 is used for simple crates because its lowest 2021 edition. |
Pinning dependencies is very restrictive and can easily break downstream, so we are highly unlikely to do that. The most practical choice is to rely on the Nightly MSRV-aware resolver to generate an appropriate Cargo.lock file. |
Nightly MSRV resolver is broken and it won't be fixed to resolve dependency trees correctly. It will work only if all crates in tree have MSRV information because author don't have courage to implement proper tree walking strategy like other package managers (npm, apt, dnf). It don't and won't support case when you have tree MSRV crate -> crate without msrv -> msrv crate. So you can't count on it to do much good. |
All |
getrandom and bincode doesnt |
Either way, it does not change the outcome: we will not be pinning dependency versions since it's too disruptive. |
@hsn10 we (also @newpavlov) experimented with pinning dependencies in library crates as you're suggesting in the @RustCrypto ecosystem to preserve MSRV, and it ran into huge ecosystem incompatibilities and breakages which are still ongoing years later. In 20/20 hindsight, such pinning was very much a mistake. While it might seem like a nice solution at first it creates incompatibilities that don't need to exist and valid crate combinations being rejected. Where crates upgrading their MSRV might be a minor annoyance, incompatible dependency versions create an unsolvable problem (or rather, a problem that can only be solved by removing the overly restrictive bounds). The only people who should be pinning in their Cargo.toml to preserve MSRV are authors of |
For added emphasis, Cargo published official guidelines on this based on the negative experiences caused by using version requirements for MSRV, see https://doc.rust-lang.org/nightly/cargo/reference/specifying-dependencies.html#multiple-requirements
I need to post an update on the tracking issue. We discussed it in a recent cargo team meeting and are considering dropping |
Where is this conversation being held? I'd love to chime in: we don't use it yet in zerocopy, but are very interested in using it in CI. We are perennially afraid that we've accidentally introduced a dependency on some aspect of a crate which was introduced later than the version specified in our Cargo.toml deps. See e.g. this silly workaround. |
Blocker:
Zerocopy v0.8 — Release Roadmap google/zerocopy#671Planned breaking changes for rand 0.9 are:
rand
useResult
(Error handling of distributions::Uniform::new #1195, API differences between Uniform and Bernoulli #1211)FromSeed
traitReplacing rand_chacha with chacha20 #1348chacha20: returning rand_core feature RustCrypto/stream-ciphers#333RNG 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::gen
to avoid conflicting with a keyword in Rust 2024 #1435scale
parameter for the uniform float distribution. #1301 or UniformFloat: allow inclusion of high in all cases #1462Possibly also:
Non-breaking TODOs:
The text was updated successfully, but these errors were encountered: