> 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. > > 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, Xu > > >> >> -Ivan >>
