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
