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
