Branches during Avatica release

[Julian Hyde <jh...@apache.org>]

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

Re: Branches during Avatica release

[Julian Hyde <jh...@apache.org>]

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 <jo...@gmail.com> 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<ja...@apache.org>  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<jh...@apache.org>  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
>>>> 
>> 

Re: Branches during Avatica release

[Josh Elser <jo...@gmail.com>]

Kind of defeats the purpose using the maven-release-plugin, IMO :)

Jacques Nadeau wrote:
> On other projects we just bump master from 1.7.0-SNAPSHOT ->  1.8.0-SNAPSHOT
> without involving the release plugin.
>
> On Sat, Mar 12, 2016 at 7:59 PM, Josh Elser<jo...@gmail.com>  wrote:
>
>> 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
>> bump).
>>
>> 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<jo...@gmail.com>   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<ja...@apache.org>
>>>>>   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<jh...@apache.org>
>>>>>>   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
>>>>>>>
>>>>>>>
>>>>>>>
>

Re: Branches during Avatica release

[Jacques Nadeau <ja...@apache.org>]

On other projects we just bump master from 1.7.0-SNAPSHOT -> 1.8.0-SNAPSHOT
without involving the release plugin.

On Sat, Mar 12, 2016 at 7:59 PM, Josh Elser <jo...@gmail.com> wrote:

> 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
> bump).
>
> 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<jo...@gmail.com>  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<ja...@apache.org>
>>>>  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<jh...@apache.org>
>>>>>  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
>>>>>>
>>>>>>
>>>>>>
>>

Re: Branches during Avatica release

[Josh Elser <jo...@gmail.com>]

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 
bump).

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<jo...@gmail.com>  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<ja...@apache.org>   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<jh...@apache.org>   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
>>>>>
>>>>>
>

Re: Branches during Avatica release

[Sarnath <st...@gmail.com>]

It would serve like a 'marker' indicating Avatica's independence day. And
that's good in certain ways - You will be able to inspect, audit from a
future point, just in case if you have to.

PS: Me not a calcite developer... Just a developer developing his
development skills and partipating in development forums of interest.

Re: Branches during Avatica release

[Jacques Nadeau <ja...@apache.org>]

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 <jo...@gmail.com> 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<ja...@apache.org>  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<jh...@apache.org>  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
>>>>
>>>>
>>

Re: Branches during Avatica release

[Josh Elser <jo...@gmail.com>]

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<ja...@apache.org>  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<jh...@apache.org>  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
>>>
>

Re: Branches during Avatica release

[Julian Hyde <jh...@apache.org>]

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 <ja...@apache.org> 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 <jh...@apache.org> 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
>> 

Re: Branches during Avatica release

[Jacques Nadeau <ja...@apache.org>]

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 <jh...@apache.org> 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
>