A merge commit if we really must. We’ve managed to do without them until now, and the history is simpler for it. Because Calcite’s pace of development is fairly slow, it’s no hardship to close master branch for a few days. This might all be academic — it looks as if avatica-1.7.0-rc1 is going to pass.
> On Mar 11, 2016, at 2:29 PM, Josh Elser <[email protected]> wrote: > > Negative on the extra commits. The only thing in branch-avatica-1.7 over > master are the two maven-release-plugin commits. I rebased before cutting rc1. > > As long as we're ok with a merge commit in history, I don't think we need to > lock master. > > Julian Hyde wrote: >> The release (and the two maven commits corresponding to the release) doesn’t >> need to make it to master but any other changes we make to avatica up until >> the release (bug fixes, documentation patches) will probably need to come >> back to master branch. >> >>> On Mar 11, 2016, at 2:18 PM, Jacques Nadeau<[email protected]> wrote: >>> >>> I'm not understand why would need to do a rebase and force push. I'm not >>> aware of any requirement that a release be in the master branch history. >>> (I'm generally fine with this type of thing but was hoping to get some >>> patches merged this weekend or early next week.) >>> >>> On Fri, Mar 11, 2016 at 10:19 AM, Julian Hyde<[email protected]> wrote: >>> >>>> tl;dr: I suggest that we avoid committing to master branch until the >>>> Avatica release is final. >>>> >>>> Avatica is being released from branch-avatica-1.7, while Calcite >>>> development continues on master. After the release, we'll want to >>>> bring any Avatica changes back onto master branch, which will become >>>> Avatica's dev branch again. It would nice (not critical) if we could >>>> avoid a rebase and force push after the Avatica release, so I suggest >>>> that we avoid committing to master until the Avatica release is final >>>> (probably early next week). >>>> >>>> Julian >>>> >>
