Outline path towards 1.0.0

[twmb]

According to semver, major version zero (0.y.z) is for initial development, anything may change at any time, and the public API should not be considered stable.

The last big tracker I recall in this project was for the 0.6 release.

Although this crate is ubiquitous (over 10M downloads!), it is hard to stomach needing to change production applications due to eventual API churn.

Would it be possible to checklist 1.0.0 blockers?

[dhardy]

Indeed, anything may change, but not within the same 0.y series. The same is true when going from 1.0 to 2.0.

We do our best to avoid breaking changes within a 0.y series and make transition to 0.y+1 easy.

I could enumerate several of the open issues as blockers on 1.0, but I don't think tracking them here is useful; perhaps instead labels or milestones would be better. But I also don't think this discussion is particularly useful when we have several unresolved PRs and issues which could significantly impact on the crate's design — i.e., if you want to help development, start by going through the existing issue list.

[gilescope]

As some crates move to 1.0 they are finding the need to purge rand from their public api to maintain backward compatibility (at the detriment to usability).

Rust doesn't have a batteries included model, but if it did rand would be it and it would help the ecosystem move forward if there was a stable way to do random numbers. Is it time yet to release a long term stable 1.x version? If not is there a path to this?

[dhardy]

Rand depends on getrandom which is not stable yet, so that is the first step.

In the mean time, any use of rand as an internal dependency (not affecting the downstream API) doesn't have to worry.

[gilescope]

I guess rand-core being 1.0 would be the first step once we have assurances from getrandom?

[dhardy]

The rand crate has more unknowns than rand_core, so it makes sense to get #1165 done first.

[newpavlov]

We also need for rust-lang/rust#60551 to be resolved on stable, since we want BlockRngCore to be defined roughly as:

pub trait BlockRngCore {
    type Item;
    const ITEMS: usize;
    fn generate(&mut self, block: &mut [Self::Item; Self::ITEMS]);
}

[gilescope]

That feels like a 2.0 to me given that it could easily be a year off before that's in nightly.

[dhardy]

I agree that waiting on future language features is a bad idea. (I'm also not aware of a pressing need for that change.)

But I'm curious: if you readily consider the possibility of 2.0 breaking things, then what's so bad about 0.8? Just the same, we don't readily push breaking changes.

[newpavlov]

That feels like a 2.0 to me given that it could easily be a year off before that's in nightly.

Please, read the linked issue. It already works on nightly. I don't see much point in releasing 1.0, while we expect we will need breaking changes to be released in an year or two. Doubly so for a such high profile project as rand. 0.x.y versions works just as good as x.y.z. In my opinion, 1.0 is all about signaling long-term stability of a crate.

I'm also not aware of a pressing need for that change.

type Results: AsRef<[Self::Item]> + AsMut<[Self::Item]> + Default; is a clear unergonomic hack, which has caused unsoundness issues to boot.

[gilescope]

Each point release is a breaking change at the moment before 1.0. Tbh, I am hoping 0.9 release is staved off until I have at least got things upgraded to 0.8. It takes time for the upgrades to roll through the hierarchy. I know rust might regard rust 2.0 as a failure in a backwardly compatible sense but I don’t think crates should view things this way.

…

On Thu, 21 Oct 2021 at 09:21, Artyom Pavlov ***@***.***> wrote: That feels like a 2.0 to me given that it could easily be a year off before that's in nightly. Please, read the linked issue. It already works on nightly. I don't see much point in releasing 1.0, while we expect we would need breaking changes to be released in an year or two. Doubly so for such high profile project as rand. 0.x.y versions works just as good as x.y.z. In my opinion, 1.0 is all about signaling long-term stability of a crate. I'm also not aware of a pressing need for that change. type Results: AsRef<[Self::Item]> + AsMut<[Self::Item]> + Default; is a clear unergonomic hack, which has caused unsoundness issues to boot. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#693 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGEJCDLKUAVH5TANHL4LRDUH7ESFANCNFSM4GQAUGBQ> .

[dhardy]

rand v0.8 is now 10 months old, and has had four (non-breaking) patch releases since then. v0.7 is over two years ago. In the future we expect v0.9 (difficult to say when, but probably at least a year after v0.8) and, if all goes well, v1.0 (with minimal breaking changes) soon after that. This essentially gives you a year to jump to the next release, and if things go to plan you can skip v0.9 and jump to v1.0. So I don't see any issue here really?

Of course, landing v1.0 and having some "stability guarantee" is nice (though that's only applicable if we don't jump to v2.0 soon after, which we certainly don't plan to). I also don't see minor releases like v1.1 as particularly useful since Cargo will not unify crates across minor versions, leading to compatibility issues (and potentially dependency bloat).

TLDR: I still don't see the point of 1.0. What matters is a low frequency of breaking/non-crate-unifying updates IMO.

[gilescope]

It's a fair point. rand is so deep in the stack and so commonly used, that it just takes longer than most for those version changes to peculate everywhere. If 0.9 is a while away then that gives a bit more time for the crates to consolidate. I don't mean to criticize, sorry if it came over that way.

[twmb]

I've since moved on from rust, but since I've been pinged about this issue, I'll chime back in a bit. The point of 1.0 is so that I know the API will not change. There will be no code for me to update. I can pull in all new patches for any bugs.

This library is somewhat treating the 0.x releases as stable, but with enough wiggle room to break the API at indeterminate times in the future. Unfortunately, as a library user, this signals to me that at some point, a dependency of mine may break, and then unless I work to change my code, I will miss any future bug fixes or patches after that point.

Generally, a 2.0 release is avoided as much as possible. A library author may even continue to support 1.x with bug fixes even if a 2.x is released. That basically does not happen with 0.x releases.

IMO, that 1.0 is a major milestone for any programming language, and programming languages strongly try to avoid major version bumps, are both pretty strong signals that 1.0 stabilization is important to some people / organizations. I'm not sure it's the burden of commenters here to be convincing enough as to why it's important.

That said, I know that my usage of this crate has never broken in the years I used it. To me it seems that the main APIs of this crate are stable. It might be worth it to just split unstable parts into separate crates that are then merged into this crate as a feature release once those separate areas are stable (this is the approach I use in my own Go libraries).

[dhardy]

A library author may even continue to support 1.x with bug fixes even if a 2.x is released. That basically does not happen with 0.x releases.

The way I see it, this question concerns available support far more than anything else. Yes, we've rarely bothered patching old 0.x releases. Why? Because (1) we don't usually get asked to and (2) because we don't have a budget for it. We don't have a budget full stop (which has quite a bit to do with why development is slow). I don't see how this has anything to do with version numbers.

And, regarding fixes, there are a couple of memory-safety issues we've patched, but nothing with any known exploits.

Programming languages have very strong reasons to avoid breaking releases — we know how long it took to migrate to Python 3.x. With libraries like Rand there's less of an issue since multiple versions can be used simultaneously, though still issues (mostly with shared RNGs and bloat IIUC).

To me it seems that the main APIs of this crate are stable.

We do try to minimise major breakage. Switching gen_range to take a Range was probably the most significant breakage in 0.8. We moved most of the non-trivial distributions out to rand_distr precisely so that these would not impede stabilisation of rand. But, yes, there will probably still be some minor API breakage before 1.0 (e.g. #1195).

[Kixunil]

If some traits in rand_core can't be stabilized yet maybe temporarily move them to a separate crate (rand_core_ext?) so that at least the most important ones can be implemented.

I also noticed that fill_bytes doesn't use MaybeUninit but I'm not sure if adding it would be a good idea.

[dhardy]

To be honest, the biggest blocker to 1.0 is the lack of motivated contributors/maintainers. Some form of funding or backing organisation would probably help; currently we're just volunteers here.

I don't know whether we'd make breaking changes to rand_core as outlined above, but it doesn't make much sense moving this trait out (all the crypto/block RNGs, including StdRng, use it).

Regarding MaybeUninit, we've had a few discussions, e.g. #1080. It's an optimisation with close to negligible benefit. Somehow it got merged into getrandom even though the benefit there is entirely within the margin of error.