I've never been a fan of the Calcite process where there is a strong desire
to keep the release commit in the master branch & locking the branch.
I prefer branching when we want to start a release. The branch can always
be cherry-picked to/from as necessary and/or re-forked as necessary. When
the branch occurs, the master get's bumped to the next snapshot version.
I prefer to avoid force-pushing on master.
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
> >
> >
>
