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