How to Retain Used By After Migrating to an Apache Organization

[funky-eyes]

我有几个想法：

1. 发布apache-seata的包(该版本不做包名迁移,依旧保留io.seata的包,也就是发布一个seata-all的apache org的包)，发布一个io.seata:seata-all 1.9.0 内部无任何代码，只有maven依赖apache-seata-all的依赖包,并且去除shade io.seata的操作，这样只要有用户使用io.seata下的seata-all，就会引入org.apache.seata的依赖,随着时间,无论使用apacheseata还是io.seata的用户都会算到org.apache.seata:seata-all中.
   该方案依旧会清空当前的usedby,但是如果用户用新版的io.seata就会引入apache-seata,这样用户无论是使用io.seata的最新版,还是apacheseata,二者均会记录到apacheseata:seata-all中,有助于快速提升apache seata的used by数量.

2. 发布一个io.seata下的seata，也是一样没有任何代码，被apache-seata所依赖，然后used by这块统计延续使用io.seata:seata-all即可,
   usedby会得到保留,因为无论使用io.seata还是apache.seata,最终都包含io.seata:seata-all

3. 新增一个seata-complete模块内部包含io.seata:seata-all,将需要保留的api/注解/拦截器等都迁移到该模块中,最终打包为org.apache.seata:seata-all,该依赖包含org.apache.seata:seata-complete该模块再引入io.seata:seata-all,这样用户使用org.apache.seata时,便依赖了io.seata,而io.seata中不再是个空包而是存储少量的api/注解/拦截器等需要向下兼容的类.used by改为 org.apache.seata:seata-all,
   此方案依旧会清空当前的usedby.

如果社区的各位有更多想法欢迎在此讨论

I have a few ideas:

1. Publish the apache-seata package (this version does not do package name migration, still retains the io.seata package, that is, publishes a seata-all apache org package), publishes an io.seata:seata-all 1.9.0 There is no code inside, only maven depends on apache-seata-all's dependency package, and the shade is removed io.seata, so that as long as a user uses seata-all under io.seata, the dependency of org.apache.seata will be introduced, and over time, users who use both apacheseata and io.seata will be counted in org.apache.seata:seata-all. This solution will still clear the current usedby, but if the user uses the new version of io.seata, apache-seata will be introduced, so that whether the user is using the latest version of io.seata or apacheseata, both will be recorded in apacheseata:seata-all, which helps to quickly increase the number of used by of apache seata.

2. Publish a seata under io.seata, which is also without any code, and is dependent on apache-seata, and then used by This statistic continues to use io.seata:seata-all, and usedby will be retained, because whether you use io.seata or apache.seata, it will eventually contain io.seata:seata-all

3. Add a seata-complete module that contains io.seata:seata-all, migrate the api/annotation/interceptor that needs to be retained to this module, and finally package it as org.apache.seata:seata-all, the dependency contains org.apache.seata:seata-complete, and then introduce io.seata: seata-all, so that when you use org.apache.seata, you are relying on io.seata, and io.seata is no longer an empty packet but stores a small number of APIs/annotations/interceptors and other classes that need to be backwards compatible. used by to org.apache.seata:seata-all, this solution will still clear the current usedby.

If you have more ideas from the community, please feel free to discuss them here

[lightClouds917]

1方案排除；
2，3方案，考虑循环依赖问题；
细化下包的引用路径；
@funky-eyes

[funky-eyes]

方案2比较好做，只要发布一个空的seata-all，版本可以是改成非常大的数字加英文描述不允许使用。这样没有循环依赖问题，而且只有1.x的seata-all是不改包名的，但是涉及发版合规问题，可能发不了这种包。

方案3可以考虑 org.apache.seata:seata-xxxx 依赖 io.seata:seata-all ，这个seata-all中只有io.seata的api，注解等向下兼容的类，但是跟方案二一样，存在这个seata-all能否被允许发版的问题，也涉及到是否会有用户去用了这个版本的seata-all。至于循环依赖问题，可以让apache-seata对其强依赖，ioseata对apache-seata改为scope provided来避免

以及目前我根据方案1和方案3想了一个新版本，就是发布一个apacheseata1.8.1或1.9的版本，再接着发布一个io.seata去依赖apacheseata对应版本，这样用户使用ioseata也使用了apacheseata，io.seata:seata-all只需要将pom中的依赖全部去除，只引入一个org.apache.seata的版本去发版，因为他作为一个兼容过渡版本，在合规上是允许在孵化期间沿用io.seata这个包发的。同时要在apache seata中将旧版的api，注解等类保留到seata-complete（该模块不会被打包成seata-all，也不会有循环依赖问题）以便向下兼容。然后usedby在发版后在配合文档，博客等方式让用户升级到高版本，一段时间后改为apache seata去统计。虽然这种方式会丢失一些usedby，但是在发版合规性和代码调整等方面是改动较小的

Option 2 is better to do, just release an empty seata-all, the version can be changed to a very large number plus the English description is not allowed to use. This way there is no circular dependency problem, and only 1.x seata-all is not to change the name of the package, but it involves the release of the version of compliance issues, may not be able to issue such packages.

Option 3 can consider org.apache.seata:seata-xxxx dependency on io.seata:seata-all , this seata-all has only io.seata api, annotations and other backward compatible classes in it, but like option 2, there is the question of whether this seata-all can be allowed to distribute the version, which also involves the question of As for the circular dependency problem, you can make apache-seata strongly dependent on it, and ioseata can change scope provided to apache-seata to avoid the problem.

As well as currently I think of a new version based on option 1 and 3, which is to release a version of apacheseata 1.8.1 or 1.9, and then proceed to release an io.seata to depend on the corresponding version of apacheseata, so that the user using ioseata also uses apacheseata, io.seata:seata- all just need to remove all the dependencies in the pom, and only introduce a version of org.apache.seata to send the version, because he as a compatibility transition version, in compliance is allowed to be sent during the incubation period along the package io.seata. Also to keep the old api, annotations, and other classes in apache seata to seata-complete (the module will not be packaged as seata-all, and there will be no circular dependency issues) for backward compatibility. Then usedby will let users upgrade to a higher version after the release with documentation, blogs, etc., and then change to apache seata after a period of time. Although this way will lose some usedby, but in terms of release compliance and code adjustments, it is a small change.

[lightClouds917]

io.seata 可以发出；
1.x不允许修改坐标；
方案3继续细化；本地先走通；确定了再正式推进；
used by 必须保留；
repackage;

[funky-eyes]

如图上图所示，将seata-compatible作为old package的存放点是可行的，但是作为seata-all去打包，反被apache seata依赖是不可行的，因为循环依赖的存在无法通过maven直接打包成功。
所以我觉得由于ioseata还是可以不改groupid去发，我当时想的结合方案
1.按照方案三，先通过compatible去解开新老package的管理，分离开，依赖关系只会有compatible依赖orgapacheseata，因为compatible只是接口
2.然后seata-all这个包发一个空包，内部没实现，只是用来统计used by，版本号可以起一个statistics，类似类似这样的标识，不代表正确版本
3.在org.apache.seata中引用这个统计用的seata-all

As shown in the figure above, seata-compatible as the old package repository is feasible, but as seata-all to package, anti-apache seata dependency is not feasible, because of the existence of circular dependencies can not be packaged through the maven direct success. So I think because ioseata can still not change the groupid to send, I was thinking of combining the program

1. according to program three, first through compatible to unlock the management of the old and new package, separated from the dependencies will only have compatible dependency orgapacheseata, because compatible is just the interface
2. then seata-all this package to send an empty package, the internal did not realize, just used to statistics used by, the version number can be a statistics, similar to such a logo, does not represent the correct version
3. in the org.apache.seata reference to the statistics used by the seata-all