Cool, look good to me -- Thanks Xiaolong Ran
> 在 2020年1月17日，下午9:24，Chris Bartholomew > <chris.bartholo...@kafkaesque.io.INVALID> 写道： > > +1 > Makes a lot of sense to me. Thanks, Sijie. > > Cheers, > Chris > > On Fri, 17 Jan 2020 at 07:41, Sijie Guo <guosi...@gmail.com> wrote: > >> Hi all, >> >> As we are discussing cutting a release for 2.4.3 in another thread, we >> should discuss how to label the changes (pull requests) for minor releases. >> >> Currently, we used milestones for both major releases (e.g. 2.5.0) and >> minor releases (e.g. 2.4.3). A change will be first merged to master and >> released for the upcoming major release, and the change can *potentially* >> be cherry-picked to a branch for patching a minor release. >> >> For example, let's say pull request X is merged to master and released in >> 2.5.0. If we need this change to be committed for a 2.4.3 release, we can't >> simply change the milestone to 2.4.3 because this change is already marked >> as released in 2.5.0. >> >> The limitation of milestones introduces the troubles for managing >> concurrent major and minor releases. Hence we need to look for a solution >> for addressing the problems. >> >> I am proposing the followings: >> >> 1. We keep using milestone *ONLY* for major releases, such as 2.5.0, 2.6.0 >> and etc. >> 2. We DONT use milestones for minor releases. >> 3. We use `release/x.y.z` labels for minor releases, such as 2.4.3, 2.5.1 >> and etc. >> >> In this way, we are able to track which releases that a pull request is >> included in. >> >> Hence the merge process will be much clearer. >> >> 1) when merging a pull request, add the milestone (major release) to this >> pull request that it belongs. >> 2) if this pull request is needed for a minor(/patch) release for a >> previous major release, add the minor release label. >> 3) at the time of cutting a minor release, the release manager can go >> through all issues labeled for it and cherry-pick to the given branch. >> >> In the future, we can introduce the merge tool (or a merge bot) to automate >> this merge or cherry-pick process if needed. >> >> Thoughts? >> >> - Sijie >> > > > -- > Chris Bartholomew > Kafkaesque > chris.bartholo...@kafkaesque.io
