It seems that there is no objection so far. I am converting this thread into a voting thread to adopt this pattern.
- Sijie On Sat, Jan 18, 2020 at 7:23 AM xiaolong ran <ranxiaolong...@gmail.com> wrote: > 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 > >
