Skip to content
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

Any guidance on keeping reproducibility from seeded RNGs? #538

Closed
cuviper opened this issue Jun 30, 2018 · 3 comments
Closed

Any guidance on keeping reproducibility from seeded RNGs? #538

cuviper opened this issue Jun 30, 2018 · 3 comments

Comments

@cuviper
Copy link
Contributor

cuviper commented Jun 30, 2018

In rust-num/num-bigint#53, the author is offering a faster way to generate the random bits for a BigUint. This is great, but it occurs to me that this will change what value is generated by a seeded RNG, and this could be considered a kind of breaking change. Do you have any guidance in this area?

@cuviper cuviper changed the title Any guidance on keeping reproducability from seeded RNGs? Any guidance on keeping reproducibility from seeded RNGs? Jun 30, 2018
@cuviper
Copy link
Contributor Author

cuviper commented Jun 30, 2018

I guess this is the value-stability discussed in #408, whereby we should call this a breaking change?

@dhardy
Copy link
Member

dhardy commented Jul 1, 2018

This is something we haven't finalised our policy on yet. Since num-bigint is not yet stable (like Rand) I guess we shouldn't worry too much.

IMO value-breaking changes should at least be mentioned in the changelog and should not land in "patch" versions, but I can't tell other crate authors what to do.

Value-stability is not just about random number generation, but is probably more important here than elsewhere, so I suppose it would be useful if we have an official policy on this that other crates can refer to (should they wish)?

@vks
Copy link
Collaborator

vks commented Jul 9, 2018

I don't think it could be considered a semver breaking change, but I agree that we should not break reproducibility in patch versions (except maybe for bugfixes).

@dhardy dhardy mentioned this issue Jul 9, 2018
@dhardy dhardy closed this as completed Jul 31, 2018
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

No branches or pull requests

3 participants