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

Time for a v1.0.0 #64

Closed
fotinakis opened this issue Mar 30, 2016 · 3 comments
Closed

Time for a v1.0.0 #64

fotinakis opened this issue Mar 30, 2016 · 3 comments

Comments

@fotinakis
Copy link
Owner

Note to self, it's time to release a 1.0 release, since this is definitely being used in production in many places.

Need to identify if there are any blockers to this happening, or if we should just do it.

@fotinakis
Copy link
Owner Author

fotinakis commented May 24, 2016

It's confusing right now because semantic versioning dictates that we go from "v0.12.0" to "v0.13.0" for a small backwards-compatible feature addition, and then people have to use ">0.12" as the "safe" version pin. After a 1.0, users could use ">1.0" in order to get >= 1.0 but < 2, which I think is clearer.

I'll probably just do this soon, since we're in a pretty good spot and already make changes in backwards-compatible ways.

The only thing I really want to clean up before 1.0 is the symbol/string potential conflict thing from #47 (comment) — unless anybody out there has strong opinions about other 1.0 necessities.

@fotinakis
Copy link
Owner Author

I'm going to just tag a v1.0.0 now since there are a bunch of users of this in prod. No changes from v0.16.2 (what a version number that is!).

@fotinakis
Copy link
Owner Author

v1.0.0 launched!

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

1 participant