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 > > > > 申远 > > >
