Version 1.0
frewsxcv opened this issue · comments
What does a 1.0 release look like? Personally, I feel like this crate is pretty feature complete as-is that it could be close to a 1.0 release.
Thanks for starting this discussion @frewsxcv. I agree that we are pretty close to 1.0.
I think #43 is the biggest open question. We can't currently support lifetime parameterized types because of the shrink method and its signature.
Relatedly, I've been thinking for a while that we might want to remove the shrink method completely and only support "internal reduction", i.e. what happens with cargo fuzz tmin where you (or the fuzz engine) reduce the byte string rather than the structured type created from the byte string via Arbirary. This would remove a bunch of code from the crate and make the API surface smaller. In practice I've also found cargo fuzz tmin to be easier to use than Arbitrary::shrink and I've always been satisfied with the amount it was able to reduce the test case.
Yeah I think we're pretty close to 1.0 though we should maybe try and fix the "replace main" thing and some of the shrinking stuff
The replace main thing is for the libfuzzer crate, yeah?
Yeah, fuzz targets shouldn't have to do that IMO.
Also, I posted this elsewhere but we should probably have a "major" pre 1.0 release before 1.0 for a smooth transition
1.0.0-rc1 has been published! what else are we considering including in 1.0.0? no-std? more reference implementations now that we have a lifetime param?
1.0 development lives on this branch https://github.com/rust-fuzz/arbitrary/tree/staging-1.0
Would be good to advertise the 1.0 rc on users.rust-lang.org, r/rust, and twitter and give a deadline for when we expect to publish 1.0 (two weeks?).
1.0.0-rc1 has been published! what else are we considering including in 1.0.0? no-std? more reference implementations now that we have a lifetime param?
I personally can't think of any solid use case for no-std. Even if the system under test is no-std, the tests/fuzz targets don't have to be, and if your target has enough for libfuzzer, it should have enough for std. Not sure about other fuzz engines... Mostly it seems like adding no-std support would be a bunch of busy work that no one would end up actually using but would impose additional maintenance and CI overheads on us.
impl<'a> Arbtirary<'a> for &'a [u8] would be nice to sneak in there.also
That's all I can think of.
Potential breaking change we might want to make before 1.0: should Unstructured::choose's result type be an Option<T> and it should return None rather than panicking when given an an empty set of choices?
Thinking out loud, but noticed we have a get_bytes method on Unstructured. Wonder if we should drop the get_ prefix to match Rust's convention of not having get_ prefixes. I don't feel strongly, just something that came to mind. I'm working on the &'a [T]&'a [u8] impl now.
Wonder if we should drop the
get_prefix to match Rust's convention of not havingget_prefixes.
Sounds reasonable to me.
Wonder if we should drop the
get_prefix to match Rust's convention of not havingget_prefixes.Sounds reasonable to me.
Just skimmed through cargo doc on the staging-1.0 branch and things are looking good! Anyone else see anything else worth changing before 1.0?
Opened a pull request for 1.0.0: #72
Anything else to update besides the changelog?
I'm a little concerned with releasing 1.0 immediately because, AFAIK, we haven't advertised the release candidates at all, so we don't know if there is anything we're overlooking that people would find by playing with it in their existing code bases.
I think it makes sense to post to users.rust-lang.org, r/rust, and on twitter with a link to the changelog and instructions on how to try out the release candidate (perhaps these instructions could be embedded in the changelog?), and then give it a week or two after the announcement before we actually release 1.0.
I can make these posts if you don't want to, @frewsxcv.
My thinking is if we do overlook something major in the 1.0 design, we can fix it in a follow-up release, and if necessary a 2.0 release. But I acknowledge that's not how everyone prefers to release things in the open source world, so it's not something I feel strongly about. I do appreciate the thought the thought and consideration you're putting in to make sure the 1.0 is really solid 💟. In general, I've been feeling impatient recently which is definitely affecting my headspace around this.
I can make these posts if you don't want to, @frewsxcv.
I've passed the upper bound of amount of time I allocated for myself for this, so I'd love to hand this off to someone else, whomever has capacity.
EDIT: Removed a redundant phrase
Thanks again for all your work on pushing this to 1.0 @frewsxcv. Sorry this advertising stuff got dropped on the floor, this shouldn't have stretched on this long, and if we had started advertising earlier I think things would have been smoother and not as drawn out.
I'll make a new rc release with the unreleased stuff in 1.0-release and then post to various places.
Doing an rc release seems good to me
That is all that I'm aware of. Was going to fix that and cut the 1.0 release on tuesday, unless something comes up.
Of course, if anyone wants to make a PR to fix that docs issue before then, be my guest :)
1.0 branch merged; making crates.io releases now.
Published on crates.io and tagged in github! 🎉
Thanks again everyone involved in this push, especially @frewsxcv!! ❤️
Twitter announcement: https://twitter.com/fitzgen/status/1364644251099820036
Thanks for wrapping all this up @fitzgen! 🙇🏻