Hi all, I think we need to discuss how to label the issues and how to cherry-pick the issues for bug fixes. Currently it is painful for doing a bugfix release. All the bug fixes are deferred to release manager cherry-picking to bug fix branches. Since master and branches are quickly diverged with changes, it is very painful for cherry-picks later and there is no clear process for cherry-pick and labelling.
Shall we consider following the process what BookKeeper is using, having a merge script to handle labelling issues/milestones and also cherry-picks? Or any suggestions on how to improve this? - Sijie On Mon, Aug 6, 2018 at 10:50 AM Sijie Guo <guosi...@gmail.com> wrote: > Hi all, > > It seems we don't have a standard for labelling milestone. sometimes I am > not lost and confused when I see a change was merged to master but marked > in a bug fix milestone. so I am raising a discussion about this. > > I think every pull request that was created based on master, which would > be merged as a commit of master, those pull requests should be first marked > as major release milestone, for example: `2.2.0` release. If a pull request > that was created based on a branch, which would be merged as a commit of > that branch, those pull requests should be marked as minor release > milestones, for example: `2.1.1` release. so that we have a clearer way on > tracking what changes have been made to what releases. otherwise it is a > bit hard to track when we have multiple releases ongoing. > > Thoughts? > > Thanks, > Sijie > >
