3. Have com.alibaba.dubbo.cache.filter.CacheFilter extend the o.a.d version and mark it as @Deprecated. This keeps API compatibility in place, and encourages users to switch out. ------- Does the compatible code need to be deleted before graduating or always exist?
2018-03-20 10:10 GMT+08:00 John D. Ament <johndam...@apache.org>: > On Mon, Mar 19, 2018 at 9:13 PM jun liu <ken.lj...@gmail.com> wrote: > > > > - Plan for a Dubbo 3.0 that does the full rename. > > > > 3.0 is on progress, can be a milestone fully rename package. > > > > > - Any APIs a user may program against, leave as com.alibaba.dubbo, > > anything > > > internal start to rename to org.apache.dubbo. > > > - Anything new added should be named as org.apache.dubbo instead of > > > com.alibaba.dubbo. This should start with the next release cycle. > > > > These two steps i think we can start from the next release cycle. > > > > > - One approach, a strangler pattern, would be to start to create > > duplicates > > > of each class in the org.apache.dubbo scheme, and have the existing > > > com.alibaba.dubbo classes extend those. > > > > This part i don’t fully understand: will the org.apache.dubbo duplicates > > make any differences when we remove the com.alibaba.dubbo ones? > > > > > Let's say you take CacheFilter as an example (just grabbed it at random > more or less) > https://github.com/apache/incubator-dubbo/blob/master/ > dubbo-filter/dubbo-filter-cache/src/main/java/com/ > alibaba/dubbo/cache/filter/CacheFilter.java > > 1. Create a class org.apache.dubbo.cache.filter.CacheFilter > 2. Copy existing contents into it > 3. Have com.alibaba.dubbo.cache.filter.CacheFilter extend the o.a.d > version > and mark it as @Deprecated. This keeps API compatibility in place, and > encourages users to switch out. > > > > > > > On 19 Mar 2018, at 7:56 PM, John D. Ament <johndam...@apache.org> > wrote: > > > > > > We don't expect the rename of all packages to happen overnight, or in > the > > > first release. It should be expected by the time you graduate from > > > incubation that the rename is complete, or at least there's an > > > understanding of how it's going to happen. I would say that > considering > > > its using a company name the rename would block graduation. Changing > > group > > > IDs should be simple as a first step. What I would recommend: > > > > > > - Plan for a Dubbo 3.0 that does the full rename. > > > - Any APIs a user may program against, leave as com.alibaba.dubbo, > > anything > > > internal start to rename to org.apache.dubbo. > > > - Anything new added should be named as org.apache.dubbo instead of > > > com.alibaba.dubbo. This should start with the next release cycle. > > > - One approach, a strangler pattern, would be to start to create > > duplicates > > > of each class in the org.apache.dubbo scheme, and have the existing > > > com.alibaba.dubbo classes extend those. > > > > > > Happy to talk through more ideas, these are mostly shots in the dark > > that I > > > have seen work in other projects to some success. > > > > > > John > > > > > > On Mon, Mar 19, 2018 at 7:29 AM shang zonghai <yiji.git...@hotmail.com > > > > > wrote: > > > > > >> > > >> > > >> > > >> 2. Shall we need to change all the java package name to org.apache.* ? > > If > > >> do this, users will encounter the upgrading problem. > > >> > > >> > > >> The current package is com.alibaba.dubbo right? Unfortunately this > > puts us > > >> into a "you have to rename it" situation. Including the company name > in > > >> the package is a problem for our branding/trademarks. > > >> > > >> > > >> 3. Now, our groupId is "com.alibaba", shall we need to change it to > > >> "org.apache"? > > >> > > >> > > >> Most projects follow a "org.apache.projectName" naming scheme. So > > >> org.apache.dubbo would be expected. > > >> > > >> > > >> > > >> Considering that a large number of users already use dubbo，Changing > the > > >> name of the package can lead to breaking the compatibility. > > >> > > >> for case 1: New users use dubbo, we should do nothing. > > >> > > >> > > >> case 2: The user is convenient to upgrade dubbo to apache version( > > >> change com.alibaba.xxx to com.apache.xx), consumer and server > upgrades > > at > > >> the same time. > > >> > > >> We can provide tools to automatically convert the package name, the > name > > >> of the extension interceptor, the package name of the xml > configuration, > > >> etc. > > >> > > >> case 3: The user is convenient to upgrade dubbo to apache version( > > >> change com.alibaba.xxx to com.apache.xx), consumer and server can't > > >> upgrades at the same time. > > >> > > >> This scenario is the most complicated, we should be compatible at the > > >> source code level，and prompting future versions will remove the > > compatible > > >> code. It is recommended that you use this tool to manually convert old > > code. > > >> > > >> > > > > >
