On Thu, Feb 21, 2019 at 10:57 AM Dave Fisher <dave2w...@comcast.net> wrote:
> > > > On Feb 20, 2019, at 6:47 PM, Sijie Guo <guosi...@gmail.com> wrote: > > > > On Wed, Feb 20, 2019 at 9:12 PM Ivan Kelly <iv...@apache.org> wrote: > > > >>> Can anyone propose a change to current release management? Otherwise it > >> is > >>> not a scalable solution because not every committer knows how to handle > >>> this situation clearly. > >> > >> I agree that not every committer knows this. > >> What has worked well for me in the past is to have _every_ commit go > >> to master, and cherry-pick nothing until it is decided that a bugfix > >> release is needed. > > > > Then the release manager goes through the list of commits that > >> occurred on the master branch since the last release on the bugfix > >> branch, select those that are required for the bugfix release, and > >> then cherry-pick those, in order, to the bugfix branch. > >> > > > > That works well for me as well. I think the community needs to come up > with > > a clear workflow for this. > > > > At minimum, a simple rule should be: > > - if a change is merged to master, it should be "tagged" for a major > > release; > > - if a change is merged directly to a branch, it should be "tagged" for a > > minor release; > > - if a change is merged to master, and then cherry-picked to a branch, it > > should be "tagged" for a major release, and then tagged for a minor > release > > after cherry-pick. otherwise if we merge a change to master but directly > > label it for a minor release, IMO this is an "inconsistent" state in a > > source repo. > > Depending on how close to a minor release the branch is on many projects > the Release Manager decides whether or not a change should be cherry picked. > > A “tag” could be used to request a cherry pick. > Yeah. If we have agreed on this direction, one proposal for the workflow can be: - for every pull request created on master, it should be associated with major release milestone. - if the committer who merges the pull request think it should be cherry-picked to a branch for minor releases, he can label this issue using `cherry-pick/<minor-release-version>` (e.g. `cherry-pick/2.3.1`). if not sure, don't attach any `cherry-pick` labels. - for every pull request created on branches (e.g. branch-2.3), it should be associated directly with minor release milestone. When it comes to release a minor release, he should : 1) go through all the issues in current master and pick the issues that are required to cherry-pick to branches, and label them with `cherry-pick` label. 2) go through all the issues label with `cherry-pick` label, and cherry-pick the issues in their commit order in master. 3) once a commit is cherry-picked to branch, remove the cherry-pick label, and change the milestone to minor release milestone. > > > > How to tag the release, and how to cherry-pick is a question to the > > community. The community should decide and vote a workflow for tagging > and > > cherry-pick changes, and *DOCUMENT* it in Pulsar website. So everyone in > > the community (including committers, contributors, and users) know > exactly > > how the release is done. > > +1 > > Regards, > Dave > > > > > > >> > >> -Ivan > >> > >
