1方案排除；
2，3方案，考虑循环依赖问题；
细化下包的引用路径；
@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.

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

如图上图所示，将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