Got it (I remember that discussion actually). The status quo is OK for us.. longer term we'll switch to using releases.
On Wed, Jan 17, 2018 at 7:50 AM Wes McKinney <wesmck...@gmail.com> wrote: > 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. >
