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