Release schedule

[benesch]

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]

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]

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

[nickolay]

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

[andygrove]

Ack. I will create a release this week. Is this a new major version ?

…

On Sun, Jun 30, 2019, 7:55 PM Nickolay Ponomarev ***@***.***> wrote: Thanks! I think it's up to @andygrove <https://github.com/andygrove> now, as he owns the package on crates.io. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/andygrove/sqlparser-rs/issues/117?email_source=notifications&email_token=AAHEBRDYFESJQUXAUK3ZUH3P5FPXRA5CNFSM4HYSJMM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY4ZEZA#issuecomment-507089508>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHEBRENK2HJ3F4WK6U5GJTP5FPXRANCNFSM4HYSJMMQ> .

[nickolay]

@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]

0.4 is released 🎉

[benesch]

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.