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