You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bookkeeper.apache.org by Sijie Guo <gu...@gmail.com> on 2017/08/11 00:42:21 UTC
Bug releases on Github
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
Re: Bug releases on Github
Posted by Sijie Guo <gu...@gmail.com>.
Okay. Let's try this to see if it help us.
I am going to merge https://github.com/apache/bookkeeper/pull/437 so
committers can start use it on merging pull requests.
Please provide any feedback on this tool. We can together improve the tool.
- Sijie
On Fri, Aug 11, 2017 at 4:55 AM, Enrico Olivelli <eo...@gmail.com>
wrote:
> Thank you. Good idea
> I hope I will be able to use it soon
>
> Enrico
>
> Il ven 11 ago 2017, 13:45 Jia Zhai <zh...@gmail.com> ha scritto:
>
> > Since it may not easy to change the permissions for contributor, This PR
> is
> > a good alternative to make it easy. Thanks a lot to make it happen.
> >
> > On Fri, Aug 11, 2017 at 7:07 PM, Sijie Guo <gu...@gmail.com> wrote:
> >
> > > I've played around github API and come up a change to the merge script.
> > It
> > > handles adding milestone, labels (area, type and release) when merging
> > pull
> > > requests. If a change is cherry-pick to a branch for bug fixes, a bug
> fix
> > > release is required to add as well.
> > >
> > > this is the pull request - https://github.com/apache/
> bookkeeper/pull/437
> > >
> > > I actually just used this script merged #424
> > > <https://github.com/apache/bookkeeper/pull/424> . This script would
> then
> > > instruct the committer to choose milestone, labels(area/type/release)
> on
> > > merging. Both the issue and the pull request were updated with same
> > > milestone, labels. So
> > >
> > > Example output:
> > >
> > > ------------------------
> > >
> > > *Choose fix milestone : options are [4.6.0] - default: [4.6.0]:*
> > > *Choose label 'area/' - options are: [bookie, build, client, docker,
> > > documentation, metadata, protocol, release, security, tests] - default:
> > > [bookie, tests] (comma separated):*
> > > *Choose label 'type/' - options are: [bug, feature, task] - default:
> > [bug]
> > > (comma separated):*
> > > *=== Apply following milestone, area, type to github issues ==*
> > > *Fix Types: bug*
> > > *Fix Areas: bookie, tests*
> > > *Fix Milestone: 4.6.0*
> > >
> > > *Would you like to update github issues with these labels? (y/n): y*
> > >
> > >
> > > *-----------------------------*
> > >
> > > Any thoughts?
> > >
> > > - Sijie
> > >
> > > On Thu, Aug 10, 2017 at 11:12 PM, Enrico Olivelli <eolivelli@gmail.com
> >
> > > wrote:
> > >
> > > > Il ven 11 ago 2017, 04:15 Sijie Guo <gu...@gmail.com> ha scritto:
> > > >
> > > > > On Thu, Aug 10, 2017 at 6:48 PM, Jia Zhai <zh...@gmail.com>
> > wrote:
> > > > >
> > > > > > 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.
> > > > > >
> > > > >
> > > > > I am not sure how to configure that. Is there any settings on
> github
> > > that
> > > > > we can configure (or ask INFRA to configure)?
> > > > >
> > > > > - Sijie
> > > > >
> > > > >
> > > > > >
> > > > > > On Fri, Aug 11, 2017 at 8:42 AM, Sijie Guo <gu...@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`.
> > > > >
> > > > Ok
> > > >
> > > > > > > - 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`.
> > > > >
> > > > Ok
> > > >
> > > > > > > - if a change is a bug fix that needs to be included in a bug
> fix
> > > > > > release,
> > > > > > > it will be labelled with that release.
> > > > >
> > > > Ok
> > > >
> > > > > > >
> > > > > > > *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?
> > > > >
> > > >
> > > > We can try. It could work. I did not see this workflow in othet
> > projects
> > > > but I have limited experience of complex github projects
> > > >
> > > > +1
> > > >
> > > > Enrico
> > > >
> > > > > >
> > > > > > > - Sijie
> > > > > > >
> > > > > >
> > > > >
> > > > --
> > > >
> > > >
> > > > -- Enrico Olivelli
> > > >
> > >
> >
> --
>
>
> -- Enrico Olivelli
>
Re: Bug releases on Github
Posted by Enrico Olivelli <eo...@gmail.com>.
Thank you. Good idea
I hope I will be able to use it soon
Enrico
Il ven 11 ago 2017, 13:45 Jia Zhai <zh...@gmail.com> ha scritto:
> Since it may not easy to change the permissions for contributor, This PR is
> a good alternative to make it easy. Thanks a lot to make it happen.
>
> On Fri, Aug 11, 2017 at 7:07 PM, Sijie Guo <gu...@gmail.com> wrote:
>
> > I've played around github API and come up a change to the merge script.
> It
> > handles adding milestone, labels (area, type and release) when merging
> pull
> > requests. If a change is cherry-pick to a branch for bug fixes, a bug fix
> > release is required to add as well.
> >
> > this is the pull request - https://github.com/apache/bookkeeper/pull/437
> >
> > I actually just used this script merged #424
> > <https://github.com/apache/bookkeeper/pull/424> . This script would then
> > instruct the committer to choose milestone, labels(area/type/release) on
> > merging. Both the issue and the pull request were updated with same
> > milestone, labels. So
> >
> > Example output:
> >
> > ------------------------
> >
> > *Choose fix milestone : options are [4.6.0] - default: [4.6.0]:*
> > *Choose label 'area/' - options are: [bookie, build, client, docker,
> > documentation, metadata, protocol, release, security, tests] - default:
> > [bookie, tests] (comma separated):*
> > *Choose label 'type/' - options are: [bug, feature, task] - default:
> [bug]
> > (comma separated):*
> > *=== Apply following milestone, area, type to github issues ==*
> > *Fix Types: bug*
> > *Fix Areas: bookie, tests*
> > *Fix Milestone: 4.6.0*
> >
> > *Would you like to update github issues with these labels? (y/n): y*
> >
> >
> > *-----------------------------*
> >
> > Any thoughts?
> >
> > - Sijie
> >
> > On Thu, Aug 10, 2017 at 11:12 PM, Enrico Olivelli <eo...@gmail.com>
> > wrote:
> >
> > > Il ven 11 ago 2017, 04:15 Sijie Guo <gu...@gmail.com> ha scritto:
> > >
> > > > On Thu, Aug 10, 2017 at 6:48 PM, Jia Zhai <zh...@gmail.com>
> wrote:
> > > >
> > > > > 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.
> > > > >
> > > >
> > > > I am not sure how to configure that. Is there any settings on github
> > that
> > > > we can configure (or ask INFRA to configure)?
> > > >
> > > > - Sijie
> > > >
> > > >
> > > > >
> > > > > On Fri, Aug 11, 2017 at 8:42 AM, Sijie Guo <gu...@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`.
> > > >
> > > Ok
> > >
> > > > > > - 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`.
> > > >
> > > Ok
> > >
> > > > > > - if a change is a bug fix that needs to be included in a bug fix
> > > > > release,
> > > > > > it will be labelled with that release.
> > > >
> > > Ok
> > >
> > > > > >
> > > > > > *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?
> > > >
> > >
> > > We can try. It could work. I did not see this workflow in othet
> projects
> > > but I have limited experience of complex github projects
> > >
> > > +1
> > >
> > > Enrico
> > >
> > > > >
> > > > > > - Sijie
> > > > > >
> > > > >
> > > >
> > > --
> > >
> > >
> > > -- Enrico Olivelli
> > >
> >
>
--
-- Enrico Olivelli
Re: Bug releases on Github
Posted by Jia Zhai <zh...@gmail.com>.
Since it may not easy to change the permissions for contributor, This PR is
a good alternative to make it easy. Thanks a lot to make it happen.
On Fri, Aug 11, 2017 at 7:07 PM, Sijie Guo <gu...@gmail.com> wrote:
> I've played around github API and come up a change to the merge script. It
> handles adding milestone, labels (area, type and release) when merging pull
> requests. If a change is cherry-pick to a branch for bug fixes, a bug fix
> release is required to add as well.
>
> this is the pull request - https://github.com/apache/bookkeeper/pull/437
>
> I actually just used this script merged #424
> <https://github.com/apache/bookkeeper/pull/424> . This script would then
> instruct the committer to choose milestone, labels(area/type/release) on
> merging. Both the issue and the pull request were updated with same
> milestone, labels. So
>
> Example output:
>
> ------------------------
>
> *Choose fix milestone : options are [4.6.0] - default: [4.6.0]:*
> *Choose label 'area/' - options are: [bookie, build, client, docker,
> documentation, metadata, protocol, release, security, tests] - default:
> [bookie, tests] (comma separated):*
> *Choose label 'type/' - options are: [bug, feature, task] - default: [bug]
> (comma separated):*
> *=== Apply following milestone, area, type to github issues ==*
> *Fix Types: bug*
> *Fix Areas: bookie, tests*
> *Fix Milestone: 4.6.0*
>
> *Would you like to update github issues with these labels? (y/n): y*
>
>
> *-----------------------------*
>
> Any thoughts?
>
> - Sijie
>
> On Thu, Aug 10, 2017 at 11:12 PM, Enrico Olivelli <eo...@gmail.com>
> wrote:
>
> > Il ven 11 ago 2017, 04:15 Sijie Guo <gu...@gmail.com> ha scritto:
> >
> > > On Thu, Aug 10, 2017 at 6:48 PM, Jia Zhai <zh...@gmail.com> wrote:
> > >
> > > > 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.
> > > >
> > >
> > > I am not sure how to configure that. Is there any settings on github
> that
> > > we can configure (or ask INFRA to configure)?
> > >
> > > - Sijie
> > >
> > >
> > > >
> > > > On Fri, Aug 11, 2017 at 8:42 AM, Sijie Guo <gu...@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`.
> > >
> > Ok
> >
> > > > > - 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`.
> > >
> > Ok
> >
> > > > > - if a change is a bug fix that needs to be included in a bug fix
> > > > release,
> > > > > it will be labelled with that release.
> > >
> > Ok
> >
> > > > >
> > > > > *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?
> > >
> >
> > We can try. It could work. I did not see this workflow in othet projects
> > but I have limited experience of complex github projects
> >
> > +1
> >
> > Enrico
> >
> > > >
> > > > > - Sijie
> > > > >
> > > >
> > >
> > --
> >
> >
> > -- Enrico Olivelli
> >
>
Re: Bug releases on Github
Posted by Sijie Guo <gu...@gmail.com>.
I've played around github API and come up a change to the merge script. It
handles adding milestone, labels (area, type and release) when merging pull
requests. If a change is cherry-pick to a branch for bug fixes, a bug fix
release is required to add as well.
this is the pull request - https://github.com/apache/bookkeeper/pull/437
I actually just used this script merged #424
<https://github.com/apache/bookkeeper/pull/424> . This script would then
instruct the committer to choose milestone, labels(area/type/release) on
merging. Both the issue and the pull request were updated with same
milestone, labels. So
Example output:
------------------------
*Choose fix milestone : options are [4.6.0] - default: [4.6.0]:*
*Choose label 'area/' - options are: [bookie, build, client, docker,
documentation, metadata, protocol, release, security, tests] - default:
[bookie, tests] (comma separated):*
*Choose label 'type/' - options are: [bug, feature, task] - default: [bug]
(comma separated):*
*=== Apply following milestone, area, type to github issues ==*
*Fix Types: bug*
*Fix Areas: bookie, tests*
*Fix Milestone: 4.6.0*
*Would you like to update github issues with these labels? (y/n): y*
*-----------------------------*
Any thoughts?
- Sijie
On Thu, Aug 10, 2017 at 11:12 PM, Enrico Olivelli <eo...@gmail.com>
wrote:
> Il ven 11 ago 2017, 04:15 Sijie Guo <gu...@gmail.com> ha scritto:
>
> > On Thu, Aug 10, 2017 at 6:48 PM, Jia Zhai <zh...@gmail.com> wrote:
> >
> > > 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.
> > >
> >
> > I am not sure how to configure that. Is there any settings on github that
> > we can configure (or ask INFRA to configure)?
> >
> > - Sijie
> >
> >
> > >
> > > On Fri, Aug 11, 2017 at 8:42 AM, Sijie Guo <gu...@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`.
> >
> Ok
>
> > > > - 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`.
> >
> Ok
>
> > > > - if a change is a bug fix that needs to be included in a bug fix
> > > release,
> > > > it will be labelled with that release.
> >
> Ok
>
> > > >
> > > > *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?
> >
>
> We can try. It could work. I did not see this workflow in othet projects
> but I have limited experience of complex github projects
>
> +1
>
> Enrico
>
> > >
> > > > - Sijie
> > > >
> > >
> >
> --
>
>
> -- Enrico Olivelli
>
Re: Bug releases on Github
Posted by Enrico Olivelli <eo...@gmail.com>.
Il ven 11 ago 2017, 04:15 Sijie Guo <gu...@gmail.com> ha scritto:
> On Thu, Aug 10, 2017 at 6:48 PM, Jia Zhai <zh...@gmail.com> wrote:
>
> > 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.
> >
>
> I am not sure how to configure that. Is there any settings on github that
> we can configure (or ask INFRA to configure)?
>
> - Sijie
>
>
> >
> > On Fri, Aug 11, 2017 at 8:42 AM, Sijie Guo <gu...@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`.
>
Ok
> > > - 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`.
>
Ok
> > > - if a change is a bug fix that needs to be included in a bug fix
> > release,
> > > it will be labelled with that release.
>
Ok
> > >
> > > *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?
>
We can try. It could work. I did not see this workflow in othet projects
but I have limited experience of complex github projects
+1
Enrico
> >
> > > - Sijie
> > >
> >
>
--
-- Enrico Olivelli
Re: Bug releases on Github
Posted by Sijie Guo <gu...@gmail.com>.
On Thu, Aug 10, 2017 at 6:48 PM, Jia Zhai <zh...@gmail.com> wrote:
> 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.
>
I am not sure how to configure that. Is there any settings on github that
we can configure (or ask INFRA to configure)?
- Sijie
>
> On Fri, Aug 11, 2017 at 8:42 AM, Sijie Guo <gu...@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
> >
>
Re: Bug releases on Github
Posted by Jia Zhai <zh...@gmail.com>.
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 <gu...@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
>