Re: [Discuss] "develop" branch for incompatible or long-term developing features

[jun liu <ke...@gmail.com>]

Hi All,

According to the discussion, I will create a new branch 2.6.x from the master and update master to 2.7.0-SNAPSHOT:
* master: 2.7.x
* 2.6.x: 2.6.x
* 2.5.x: 2.5.x

Since 2.5.x is basically compatible with 2.6.x, it seems to be an unnecessary version differentiation. So I think we should announce the EOL deadline of 2.5.x shortly.

Keeping two mutually incompatible versions evolve at the same time will inevitably bring additional workload to the Dubbo team. So we may need to figure out which patch goes against which branch beforehand. For example, new features and incompatible changes only occur in 2.7.x, while enhancements or bugfixes going to both versions.

Best regards,
Jun

> On 28 May 2018, at 10:15 PM, Huxing Zhang <hu...@apache.org> wrote:
> 
> Hi,
> 
> On Mon, May 28, 2018 at 9:08 PM, Jun Liu <liujun@apache.org <ma...@apache.org>> wrote:
>>> 1. But the naming of the branch looks inconsistent to me:
>>> 
>>> * develop: 2.7.x
>>> * master: 2.6.x
>>> * 2.5.x: 2.5.x
>>> 
>>> What about next major version, is there a branch called 2.8.x or 3.0.x?
>> 
>> Or how about separate 2.6.x from master, and start 2.7.x directly on master?  The branches would look like:
>> 
>> * master: 2.7.x
>> * 2.6.x: 2.6.x
>> * 2.5.x: 2.5.x
> 
> This looks better, master will always be the latest version.
> 
>> 
>>> 2. should every pull request sent against 2.7.x and be back ported to 2.6.x?
>> 
>> I think it will be up to us to decide which commit should be merged into the other branches and need to be done manually.
> 
> There should be a rule to guide contributors that which branch their
> pull request should be sent against.
> 
> For example, if a pull request is a general fix/enhancement, it should
> be sent against 2.7.x. On the other hand, if the fix/enhancement is
> specific to some branch, it should be sent against that specific
> branch.
> 
> Maybe we should also update the new contributor guide after the
> decision is made.
> 
>> 
>> Best regards,
>> Jun
>> 
>>> On 25 May 2018, at 5:19 PM, Huxing Zhang <hu...@apache.org> wrote:
>>> 
>>> I am generally agree with creating a new branch for incompatible changes.
>>> 
>>> 1. But the naming of the branch looks inconsistent to me:
>>> 
>>> * develop: 2.7.x
>>> * master: 2.6.x
>>> * 2.5.x: 2.5.x
>>> 
>>> What about next major version, is there a branch called 2.8.x or 3.0.x?
>>> 
>>> 2. should every pull request sent against 2.7.x and be back ported to 2.6.x?
>>> 
>>> On Fri, May 25, 2018 at 2:41 PM, Ian Luo <ia...@gmail.com> wrote:
>>>> good suggestion, it looks like we have to maintain two trunks. +1
>>>> 
>>>> On Fri, May 25, 2018 at 9:45 AM Jun Liu <li...@apache.org> wrote:
>>>> 
>>>>> I think we should create a new branch, for example “develop”, for the
>>>>> development of those upcoming incompatible or long-term features. By doing
>>>>> that, master branch and develop branch can evolve independently, and when
>>>>> develop branch is ready, it can be released with version 2.7.0, identifying
>>>>> the incompatibility with 2.6.x.
>>>>> 
>>>>> Here’s some works i think need to start on a new branch:
>>>>> - Support for java 8 or higher.
>>>>> - Package renaming required in Apache IP Clearance.
>>>>> - Transfer some extensions to Dubbo eco-system[1][2].
>>>>> - Some in compatible or long-term developing features: async api, metadata
>>>>> refactor, modularization…[3][4]
>>>>> 
>>>>> 1. https://github.com/dubbo <https://github.com/dubbo>
>>>>> 2.
>>>>> https://lists.apache.org/thread.html/a5e5e1a09cb15b1d508cf22ce2bd674ddc915ffbfe16dda55dbc90ac@%3Cdev.dubbo.apache.org%3E
>>>>> <
>>>>> https://lists.apache.org/thread.html/a5e5e1a09cb15b1d508cf22ce2bd674ddc915ffbfe16dda55dbc90ac@%3Cdev.dubbo.apache.org%3E
>>>>>> 
>>>>> 3. https://issues.apache.org/jira/browse/DUBBO-22 <
>>>>> https://issues.apache.org/jira/browse/DUBBO-22>
>>>>> 4. https://issues.apache.org/jira/browse/DUBBO-24 <
>>>>> https://issues.apache.org/jira/browse/DUBBO-24>
>>>>> 
>>>>> Best regards,
>>>>> Jun
>>> 
>>> --
>>> Best Regards！
>>> Huxing
>> 
> 
> 
> 
> -- 
> Best Regards！
> Huxing