> There could be situations where we don't
> want to include all commits in the next release candidate when a vote fails
Absolutely agree. So, to adhere to Apache's policy of not rewriting
master, you should make the release from a branch, but lock master so
that you can fast-forward merge onto master when the release is
approved.
On Fri, May 5, 2017 at 11:48 AM, Wes McKinney <wesmck...@gmail.com> wrote:
> I'm OK with rebasing master after releases for the next couple releases,
> and we'll see how it goes (though I had always thought force pushing
> upstream master was a faux pas). There could be situations where we don't
> want to include all commits in the next release candidate when a vote fails:
>
> rcX
> c1
> c2
> c3 <-- only need this commit
> c4
> c5
> rc{X+ 1}
>
> This is purely hypothetical, so we can cross this bridge when we come to
> it.
>
> Thanks
> Wes
>
> On Fri, May 5, 2017 at 12:51 PM, Julian Hyde <jh...@apache.org> wrote:
>
>> I’m fine with either proposal (holding off commits during the release
>> vote, or rebasing master afterwards).
>>
>> I agree with Julien that it’s really nice to have a simple, linear history
>> (with releases on the master branch) and since Arrow is a fairly low-volume
>> project we’re lucky we can do that.
>>
>> We’re in a similar situation in Calcite, and have arrived at a similar
>> policy, where we tend to close master during the release quiet period. I
>> will often continue to process pull-requests; I stack them in a personal
>> branch called “next-master” and commit them all to master when master
>> re-opens for commits.
>>
>> Julian
>>
>>
>> > On May 5, 2017, at 9:42 AM, Julien Le Dem <jul...@dremio.com> wrote:
>> >
>> > Alternatively we can rebase master on the release if patch have been
>> merged
>> > concurently to the release vote.
>> > I think it is fine to rebase commits that have not been released yet.
>> > (the release sha however must stay the same)
>> > I find usefull to have the release tag in the master history to know byt
>> > looking at the git log if a given patch was before or after a release.
>> Even
>> > if this info is duplicated somewhere else (jira) this one is the source
>> of
>> > truth.
>> >
>> > On Fri, May 5, 2017 at 7:18 AM, Wes McKinney <wesmck...@gmail.com>
>> wrote:
>> >
>> >> For the first few releases, we've been holding off merging patches to
>> >> master while the release vote is in progress, partially because of the
>> >> commits that the maven-release-plugin commits.
>> >>
>> >> I would propose that in the future we continue to merge patches and
>> perform
>> >> the release tag in a branch (so the release tag itself won't appear in
>> the
>> >> master timeline) so that development flow is not interrupted. I'm not
>> >> familiar with what other projects having Java libraries do, so let me
>> know
>> >> if there's a preferred workflow.
>> >>
>> >> Thanks
>> >> Wes
>> >>
>> >
>> >
>> >
>> > --
>> > Julien
>>
>>
