+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
