Closed erezsh closed 1 year ago
Also, should we be working from a dev
branch, and create a PR when we're ready for release, or work from a v1.x.x
branch, each time moving to a new one?
I think I prefer a dev branch that get's merged into master. v1.x.x
style branches would make sense IMO when we are potentially releasing new versions for older subversions (i.e. if we release a bug fix for 1.1
after 1.2
has been released). I don't think this will be that necessary for lark at the moment, so there is no reason to have the infra structure for that.
IMO one should release as often as there is something to release :) So it's useful to keep the process lightweight.
There are more sophisticated approaches (like using a release bot to automate releases on every change), but depending on how much you want to emphasize proper collaborative process (vs being God in your own repo) the following lightweight process may be worth considering:
This way the release is a minor chore that a maintainer can do any time, and there's a discussion/announcement created after the fact.
Trying the new workflow of making releases as PRs, to address issue #1301, and also give other maintainers and users the opportunity to comment about new releases as they come.
I plan to push this release today, since it's just a bugfix, but next time I will also give a timeline of a week or so ahead.
Open to thoughts and comments about this.
@MegaIng @nat-n