calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: Branches during Avatica release
Date Sun, 13 Mar 2016 03:59:53 GMT
If there was a change that was only made upstream in master (that didn't 
hit branch-avatica-1.7), there would be a merge commit when pulling 
branch-avatica-1.7 into master (to get the 1.7.0->1.8.0-SNAPSHOT version 

If we have long-term maintenance stuff, you're right, the commit could 
just go in both places.

Jacques Nadeau wrote:
> Forgiving me for being dense but why would need a merge commit (or any
> commit)? If we have a patch that needs to go in both branches, we can just
> apply it to each separately. There isn't any need for the release commit to
> be in the master branch.
> As I said, I'm just trying to understand the thinking here. I'm probably
> just missing something...
> On Fri, Mar 11, 2016 at 2:29 PM, Josh Elser<>  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<>   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<>   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

View raw message