Repository navigation
Requesting a release #349
Description
Activity
Cutting a
v0.2.9release 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:
- temporiliy reverting Add
getrandom_uninit(dest: &mut [MaybeUninit<u8>]) -> .... #291, - Having a bug fix only releae
v0.2.9 - Add back Add
getrandom_uninit(dest: &mut [MaybeUninit<u8>]) -> .... #291 - Have further discussion about the API
- temporiliy reverting Add
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.3in future without causing too much trouble downstream. Most of the ecosystem does not usegetrandomdirectly and instead relies onrand_coreand it does not expose any types fromgetrandomin its public API.Right now I do not see the need for reverting
getrandom_uninitand think that we can do release with it.Could you expand on that? Note that we may release
getrandom v0.3in future without causing too much trouble downstream. Most of the ecosystem does not usegetrandomdirectly and instead relies onrand_coreand it does not expose any types fromgetrandomin its public API.Right now I do not see the need for reverting
getrandom_uninitand 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.
I don't think your proposal conflicts with existence of
getrandom_uninit. You left thegetrandomfunction as a safe default which simply wraps the default option, sogetrandom_uninitcan be handled in the same way.But if you feel more comfortable releasing v0.2.9 without
getrandom_unitand feel strongly about it... I am fine with its temporary removal, though I personally would prefer to keep it in the new release.I don't think your proposal conflicts with existence of
getrandom_uninit. You left thegetrandomfunction as a safe default which simply wraps the default option, sogetrandom_uninitcan 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_uninitbeing a better name thangetrandom_uninit, do we want to change the name tofill_uninitnow?I think
getrandom_uninitwill be a more consistent name for now. In future we may rename it together withgetrandom.Reacted by Joe RicheySounds good, let's cut a release. I can do it Monday, but I'm OOO until then.
Published: https://crates.io/crates/getrandom/0.2.9
Reacted by Chris H-CReacted by Chris H-C
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?