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
