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

Version 1.0 #62

Closed
frewsxcv opened this issue Nov 18, 2020 · 26 comments
Closed

Version 1.0 #62

frewsxcv opened this issue Nov 18, 2020 · 26 comments

Comments

@frewsxcv
Copy link
Member

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.

@fitzgen
Copy link
Member

fitzgen commented Nov 20, 2020

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.

@Manishearth
Copy link
Member

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

@frewsxcv
Copy link
Member Author

The replace main thing is for the libfuzzer crate, yeah?

@Manishearth
Copy link
Member

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

@frewsxcv
Copy link
Member Author

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?

@frewsxcv
Copy link
Member Author

1.0 development lives on this branch https://github.com/rust-fuzz/arbitrary/tree/staging-1.0

@fitzgen
Copy link
Member

fitzgen commented Nov 30, 2020

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.

@fitzgen
Copy link
Member

fitzgen commented Dec 15, 2020

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?

@frewsxcv
Copy link
Member Author

frewsxcv commented Dec 17, 2020

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.

@fitzgen
Copy link
Member

fitzgen commented Jan 4, 2021

Wonder if we should drop the get_ prefix to match Rust's convention of not having get_ prefixes.

Sounds reasonable to me.

@frewsxcv
Copy link
Member Author

Wonder if we should drop the get_ prefix to match Rust's convention of not having get_ prefixes.

Sounds reasonable to me.

#70

@frewsxcv
Copy link
Member Author

frewsxcv commented Feb 7, 2021

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?

@frewsxcv
Copy link
Member Author

frewsxcv commented Feb 9, 2021

Opened a pull request for 1.0.0: #72

Anything else to update besides the changelog?

@fitzgen
Copy link
Member

fitzgen commented Feb 9, 2021

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.

@frewsxcv
Copy link
Member Author

frewsxcv commented Feb 9, 2021

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

@fitzgen
Copy link
Member

fitzgen commented Feb 9, 2021

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.

@Manishearth
Copy link
Member

Doing an rc release seems good to me

@frewsxcv
Copy link
Member Author

Thanks for publicizing this @fitzgen

It feels like the conversation has slowed down. Besides this, do we see anything else worth taking action on?

@fitzgen
Copy link
Member

fitzgen commented Feb 19, 2021

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 :)

fitzgen pushed a commit that referenced this issue Feb 24, 2021
@fitzgen
Copy link
Member

fitzgen commented Feb 24, 2021

1.0 branch merged; making crates.io releases now.

@fitzgen
Copy link
Member

fitzgen commented Feb 24, 2021

Published on crates.io and tagged in github! 🎉

Thanks again everyone involved in this push, especially @frewsxcv!! ❤️

@fitzgen fitzgen closed this as completed Feb 24, 2021
@fitzgen
Copy link
Member

fitzgen commented Feb 24, 2021

Twitter announcement: https://twitter.com/fitzgen/status/1364644251099820036

@fitzgen
Copy link
Member

fitzgen commented Feb 24, 2021

@fitzgen
Copy link
Member

fitzgen commented Feb 24, 2021

@frewsxcv
Copy link
Member Author

Thanks for wrapping all this up @fitzgen! 🙇🏻

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