The work flow sounds great. Currently, One problem is that contributor do not have permissions to change the Assignees, Labels, projects and Milestone for both issue and PR. It would be better if contributor could do that.
On Fri, Aug 11, 2017 at 8:42 AM, Sijie Guo <guosi...@gmail.com> wrote: > Hi all, > > Currently we are using Milestone for feature release on Github. However it > will become difficult on doing bug releases, because an issue can only be > assigned to one milestone. So I am proposing: > > - add labels for `release/x.y.z` for a given release. for example, if we > need to 4.5.1 release, we create a label `release/4.5.1`. > - for any change, it would go to master first anyway. this change will be > associated with current feature release (for example, 4.6.0) and labelled > with `release/4.6.0`. > - if a change is a bug fix that needs to be included in a bug fix release, > it will be labelled with that release. > > *How does this flow work?* > > Let's use an example: contributor A and committer B. > > - Contributor A finds a bug for 4.5.0. He files a Github issue and send a > pull request for this fix. He can assign milestone 4.6.0 (which is the > current feature release) to this issue and label it as `release/4.6.0` and > `release/4.5.1`. A doesn't have to assign milestone and labels if he > doesn't know how to do that. > > - The pull request is reviewed and approved. Committer B would use merge > script to merge this pull request. Committer B would follow the > instructions in the merge script to fill the labels, assign releases. > > - The actual milestone and labels can be updated with the merge script, so > that we are able to know what changes are included in which release. > > How does this sound? Any thoughts? > > - Sijie >
