We have been rebasing master after releases so that the release tag (and commits for the changelog, Java package metadata, etc.) appears in master. This only affects PRs merged while the release vote is open, but it's understandably not ideal.
There was a prior mailing list thread where we discussed this. The alternative is to not merge PRs while a release vote is open, but this has the effect of artificially slowing down the development cadence. I would suggest we do a 0.8.1 bug fix release sometime in the next 2 weeks with the goal of helping Ray get onto a tagged release, and establish some process to help us validate master before cutting a release candidates to avoid having to cancel a release vote. We also need to be able validate the Spark integration more easily (this is ongoing in https://github.com/apache/arrow/pull/1319 -- Bryan do you have time to work on this?) thanks Wes On Wed, Jan 17, 2018 at 12:39 AM, Robert Nishihara <robertnishih...@gmail.com> wrote: > I've noticed that specific commits sometimes disappear from the master > branch. Is this an inevitable consequence of the way Arrow does releases? > Or would it be possible to avoid removing commits from the master branch? > > Of course once we start using Arrow releases this won't be an issue. At the > moment we check out specific Arrow commits, and so there are a number of > commits in our history that no longer build because the corresponding > commits in Arrow have disappeared.
