Hi, On Mon, May 28, 2018 at 9:08 PM, Jun Liu <liu...@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 <hux...@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 <ian....@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 <liu...@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