Thanks for your detail explanation. After some thoughts during weekend, I think though users may don’t care about package names at all, we still need to give it a try for the best interest of Weex unless it’s proven impossible/impractical. We failed to make things right in the first year and second year, let’s make that right in the third year.
As for detail plan, considering there are a great deal of Java reflection code currently, proxy classes may not work well and they are also bad for performance. Here is what I think could solve the problem: "copy *everything* and let it exist under two package names”, as suggested by Myrle. Rename every package name in weex_sdk from com.alibaba.xxx to org.apache.xxx and provide a stand-along package named weex_compatible, where classes still are under package name of com.alibaba.xxx but inherit from org.apache.xxx. All further development should be under into weex_sdk with org.apache.xxx as its package name, not weex_compatible. Theoretically, existing users could import weex_sdk and weex_compatible without changing code and new users should just import weex_sdk. This is what I learnt after doing some research on Apache dubbo this weekend [1]. This refactoring may take weeks and I am not hurry to do this in next release. But I think we could gain more from it than pay for it. [1] https://github.com/apache/dubbo/tree/master/dubbo-compatible <https://github.com/apache/dubbo/tree/master/dubbo-compatible> Best Regards, York Shen 申远 > 在 2019年6月28日，18:05，Myrle Krantz <[email protected]> 写道： > > There are cases in which packages don't get renamed upon acceptance to the > incubator, precisely because of the backwards compatibility question. An > example of a TLP which doesn't use "apache" in its namespaces is groovy ( > https://github.com/apache/groovy). But it *usually* isn't a company name > there instead. > > Putting a company name there might make it more difficult to attract > contributors who don't work for alibaba. They might believe that only > employees of alibaba are welcome. > > What have communicated you communicated to your current users in the past > about the stability of your APIs? Jan is right that you could, > theoretically replace your alibaba classes with shells to redirect,. But > depending on the surface area of your API, this could be a very large > amount of work, and the result might *still* not be completely backwards > compatible. If you are going to change the package names, it is good > practice to at least indicate with semantic versioning or some other > mechanism that the new version isn't backwards compatible (you probably > already know that). > > One possibility is to just copy *everything* and let it exist under two > package names. Then you mark the classes in the alibaba packages as > deprecated, and don't make future enhancements to those classes. Users > will be incentivized to change to the new packages, but not forced to. You > can go a few cycles like that until you believe most users have adjusted > their code, and then delete the alibaba classes. Occasional backwards > incompatible changes made in a controlled, well-communicated manner do not > have to be deadly sins for every project. You will have to decide what you > feel is appropriate for your project. It *is* important that you > communicate to your users how you intend to handle situations like this > though. People find it easier to accept things when they are not surprised. > > So, the first question is: what do you think is right for your project? > > Best Regards, > Myrle > > On Fri, Jun 28, 2019 at 9:58 AM Jan Piotrowski <[email protected]> wrote: > >> As a new user, I would probably be confused to find a >> `com.taobao.xxx/com.alibaba.xxx` package name in an Apache Software >> Foundation project. >> >> As a a developer, I have no idea how to rename a Java package in a >> backwards compatible way though. Proxy classes maybe that just import >> and "redirect" to the new packages? >> >> I don't know if there were earlier Java/Android projects added to >> Apache after they already had packages names in use. Might be worth >> asking on the incubator mailing list, maybe someone can remember >> something. >> >> Best, >> Jan >> >> Am Fr., 28. Juni 2019 um 04:45 Uhr schrieb York Shen <[email protected] >>> : >>> >>> Hi, community >>> >>> As Jan pointed out[1], the Android package name in Weex is >> com.taobao.xxx/com.alibaba.xxx . >>> >>> I’d like to know whether there are rules about package name in ASF’s >> project must starts with org.apache.xxx . If so, I’d like to know if there >> is a zero-cost/low-cost upgrading method for renaming package names. It’s >> easy to rename all Android package to org.apache.xxx , but users would >> probably have a lot of complains about this renaming, which should cause >> compiling error when our users are building Android App with latest Weex. >>> >>> BTW: This is only for Android(Java Code), as there is no such >> concept(Package Name) in C++/C/Objective C/JavaScript. >>> >>> [1] https://github.com/apache/incubator-weex/issues/2148 < >> https://github.com/apache/incubator-weex/issues/2148> >>> [2] >> https://github.com/apache/incubator-weex/blob/master/android/sdk/src/main/java/com/taobao/weex/WXSDKEngine.java >> < >> https://github.com/apache/incubator-weex/blob/master/android/sdk/src/main/java/com/taobao/weex/WXSDKEngine.java >>> >>> >>> Best Regards, >>> York Shen >>> >>> 申远 >>> >>
