Skip to content

Release schedule #117

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

Closed
benesch opened this issue Jun 17, 2019 · 7 comments
Closed

Release schedule #117

benesch opened this issue Jun 17, 2019 · 7 comments

Comments

@benesch
Copy link
Contributor

benesch commented Jun 17, 2019

Extracting discussion from #105:

We should also talk a release schedule at some point. The last release was 2 months ago apparently.

We have at least one user who's requested a new release. Some options:

  • Follow the Rust approach of releasing every n weeks, regardless of what's ready and what's not.
  • Aim for a regular cadence, but tie the release to the readiness of certain issues/features/whatever.
  • Release when the list of unreleased features piles up sufficiently; basically, whenever users are asking for it.

@nickolay @andygrove thoughts?

@nickolay
Copy link
Contributor

As I said in #105 I think we should finish up the renames, then make a release. Otherwise anybody who tries out the version from crates.io will have to deal with the major changes made in the last two months and/or with the changes from #105.

Going forward I think it's up to whoever publishes the releases, since the options you listed vary in terms of time required on their part. I guess the default option is No.3 ;)

@benesch
Copy link
Contributor Author

benesch commented Jun 28, 2019

Well, the renames are done! Is it time for a release?

@nickolay
Copy link
Contributor

nickolay commented Jul 1, 2019

Thanks! I think it's up to @andygrove now, as he owns the package on crates.io.

@andygrove
Copy link
Member

andygrove commented Jul 1, 2019 via email

@nickolay
Copy link
Contributor

nickolay commented Jul 1, 2019

@andygrove Thanks! Yep, I think it ought to be bump to 0.4, given the amount of improvements and incompatible changes landed since April by @benesch and others.

Going forward should we always bump the minor version (i.e. 0.5, 0.6, etc.), given that pretty much every change we make isn't backwards compatible and the Cargo book recommends avoiding breaking changes in "patch" releases?

@andygrove
Copy link
Member

0.4 is released 🎉

@benesch
Copy link
Contributor Author

benesch commented Jul 2, 2019

Going forward should we always bump the minor version (i.e. 0.5, 0.6, etc.), given that pretty much every change we make isn't backwards compatible and the Cargo book recommends avoiding breaking changes in "patch" releases?

Yep, that makes sense to me. It would be an unusual situation indeed that resulted in a patch release. The only thing I can envision is a bug fix to the parser that doesn't require any changes to the AST.

Going to close this out, since I think the strategy of "release whenever things pile up" will work alright for the time being.

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