这个包的版本管理能不能优化一下？

[shenjianeng]

没有统一的版本管理啊，比如说：

这个版本号也太乱了，这会导致依赖的 tencentcloud-sdk-java-common 版本不知道是多少，从而引起类似于这样子的问题：

#205

改一版吧，求求官方了。

[sesky4]

hi @shenjianeng
谢谢你的建议，原因是这样的

java sdk 主要由以下部分组成：

• tencentcloud-sdk-java-common 核心库，包含 http 请求，签名等逻辑
• tencentcloud-sdk-java-xxx 各个产品库（如 tencentcloud-sdk-java-cvm )，主要包含腾讯云各个服务的 api、结构体定义

我们当前版本发布的逻辑：

• tencentcloud-sdk-java-common 核心库，每天会发布一个新版本，版本号+1
• tencentcloud-sdk-java-xxx 各个产品库，如果该产品有任何 api 变更，发新版本；否则不会发布新版本（但是无论如何所有产品的版本号都 +1，只是有的产品不会发布出去）

这么做会导致各个产品库的版本号发生“跳跃”，是基于以下考虑：

• maven 对每个 package owner 的发布速度有限制，我们以前采用每个产品每天对发布一个新版本的方式，推送太多对 maven 产生了压力，和他们沟通后，我们改为了目前有变动才发布新版本的方式
• 基于增量发布的方式，如果每个产品维护各自连续的版本号，会导致各个产品的版本号不一致，且难以和 common 库版本关联（产品库最好和common库版本保持一致），因此我们采取了跳跃的版本号发布

这个版本号也太乱了，这会导致依赖的 tencentcloud-sdk-java-common 版本不知道是多少

回到你的问题，我们建议你使用所有产品库里最新的版本作为 common 版本，如图中的 3.1.1194

[shenjianeng]

@sesky4

每个 tencentcloud-sdk-java-xxx 产品库依赖的 tencentcloud-sdk-java-common 核心库版本不一致，那我们使用方怎么办？

举个理解：

我在 1 月份引入了 tencentcloud-sdk-java-aaa 产品库，此时可能对应 common 核心库 版本号 x

在 5 月份引入了 tencentcloud-sdk-java-bbb 产品库，此时 bbb 产品库可能对应 common 核心库 版本号 z

此时，common 核心库 版本号 x 和 z 产生冲突，怎么办？

指定common 核心库 版本号？

那此时我们是不是需要回归全部的 tencentcloud-sdk-java-abcde 产品库，这个从工程角度就是不合理的。

github 上就有这种现成的案例：#205

[sesky4]

@shenjianeng

这是一个菱形依赖问题，不同语言的包管理器有不同的处理方式：

• maven 会根据 最短路径优先/最先声明优先 机制 自动选择一个 version，鉴于 aaa/bbb 对于 common 的依赖路径长度都是 1，maven 会选择位于 pom.xml 最上面的依赖（如果 aaa 在上方，则会选择 aaa 对应的 common 版本 x）
• go 语言的 最小版本选择 更适合我们的场景，在这种情况会选择 max(x, y) 作为最终版本

此时，common 核心库 版本号 x 和 z 产生冲突，怎么办？

• 最简单粗暴的解决方式就是采取类似 google 的 monorepo 方案，所有依赖在同一个 package 里，我们提供的 tencentcloud-sdk-java 包就是这样的概念，包含了所有产品，你可以在 pom.xml 中依赖这一个 package 即可，缺点是包体积较大
• 如果不希望使用 monorepo，鉴于 maven 的最短路径机制，在 pom.xml 中显式标明 common 版本是更健壮的方案；common 是向后兼容的，因此选择更新版本的 common 通常是没问题的

github 上就有这种现成的案例：#205

#205 是因为 common@x 无法兼容比它更新的 bbb@x+1 导致的，这正是 最短路径优先 方案可能产生的问题

[shenjianeng]

@sesky4

你没有抓住我问题的重点，也可能是我没说清楚。

解决方案我明白，都是简单的事情，重点是：

那此时我们是不是需要回归全部的 tencentcloud-sdk-java-abcde 产品库，这个从工程角度就是不合理的。

这样子粗暴升级 commons，会导致相关功能全部需要回归一遍，这个成本很大。

[sesky4]

明白，对于旧版本common使用新版本产品库的场景，我们后面开发会考虑这里，尽可能不破坏这种兼容性；对于会 break 的场景，使用 semver 大版本 +1 来标注