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

Requesting a release #349

Closed
chutten opened this issue Mar 23, 2023 · 8 comments · Fixed by #354
Closed

Requesting a release #349

chutten opened this issue Mar 23, 2023 · 8 comments · Fixed by #354

Comments

@chutten
Copy link
Contributor

chutten commented Mar 23, 2023

Hi! We're hoping to use this to resolve an infrequent and irritating crash in Firefox (see bug) now that we've updated our stdlib to a fixed version. Are there any plans for a release in the near term?

@josephlr
Copy link
Member

Cutting a v0.2.9 release seems reasonable to me. It seem like the only API change is in #291. However, I'm not sure if free functions are the right API for future-proofing extensions to this crate.

@newpavlov would you be OK:

@newpavlov
Copy link
Member

newpavlov commented Mar 24, 2023

@josephlr

However, I'm not sure if free functions are the right API for future-proofing extensions to this crate.

Could you expand on that? Note that we may release getrandom v0.3 in future without causing too much trouble downstream. Most of the ecosystem does not use getrandom directly and instead relies on rand_core and it does not expose any types from getrandom in its public API.

Right now I do not see the need for reverting getrandom_uninit and think that we can do release with it.

@josephlr
Copy link
Member

Could you expand on that? Note that we may release getrandom v0.3 in future without causing too much trouble downstream. Most of the ecosystem does not use getrandom directly and instead relies on rand_core and it does not expose any types from getrandom in its public API.

Right now I do not see the need for reverting getrandom_uninit and think that we can do release with it.

See #353 for the basic idea. If we think something like that is maybe worth doing, we can revert #291 and release v0.2.9 while we discuss it.

@newpavlov
Copy link
Member

I don't think your proposal conflicts with existence of getrandom_uninit. You left the getrandom function as a safe default which simply wraps the default option, so getrandom_uninit can be handled in the same way.

But if you feel more comfortable releasing v0.2.9 without getrandom_unit and feel strongly about it... I am fine with its temporary removal, though I personally would prefer to keep it in the new release.

@josephlr
Copy link
Member

I don't think your proposal conflicts with existence of getrandom_uninit. You left the getrandom function as a safe default which simply wraps the default option, so getrandom_uninit can be handled in the same way.

That seems fair. I'm good to do a release with getrandom_uninit.

Final question, in #293 (comment) we talked about fill_uninit being a better name than getrandom_uninit, do we want to change the name to fill_uninit now?

@newpavlov
Copy link
Member

I think getrandom_uninit will be a more consistent name for now. In future we may rename it together with getrandom.

@josephlr
Copy link
Member

Sounds good, let's cut a release. I can do it Monday, but I'm OOO until then.

@josephlr
Copy link
Member

josephlr commented Apr 6, 2023

Published: https://crates.io/crates/getrandom/0.2.9

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 a pull request may close this issue.

3 participants