Out of the 3 options:
A. Branching and cherry-picking commits until reaching an approved RC -- at
point of branching, updating pom.xml to next version
B. Locking master during release votes
C. Merging PRs into a "dev-staging" branch, then rebasing on master after
release
The one that is the simplest and interferes the least is A. B seems the
worst (given that we had ~300 patches in 10 weeks for the 0.3 release; this
is higher flow than normal but as the project grows that may become the new
normal). C would be OK but would require some tooling improvements in the
PR merge scripts (which is fine also).
On Fri, May 5, 2017 at 3:03 PM, Julian Hyde <jh...@apache.org> wrote:
> > 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
> >>
> >>
>
