> 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,
Dave
>
>
>>
>> -Ivan
>>
