多模块项目局部版本发布问题：仅变更依赖模块时如何处理？

你的逻辑完全没问题！不需要发布所有模块——只发布变更过的模块（B）以及依赖它的上游模块（A）就足够了，C没变动的话完全可以继续用之前的发布版本。下面是具体的处理步骤和注意事项：

1. 确认C的版本稳定性 #

• 先仔细确认C模块确实没有任何代码变更、依赖版本变更，而且当前B依赖的C版本是经过验证的稳定版本。这一步能避免后续因为C的隐性问题导致发布出意外。

2. 更新B的版本并发布 #

• 根据你对B的变更类型（bug修复、功能新增、破坏性变更），遵循语义化版本规则更新B的版本号（比如从1.0.0升到1.1.0如果是新增功能，或者1.0.1如果是bug修复）。
• 务必保证B的依赖配置中，C的版本号依然指向之前的稳定版本，不要做任何修改。
• 完成B的单元测试、集成测试后，打包并发布到你的包管理仓库（比如Maven仓库、npm registry等）。

3. 更新A对B的依赖并发布 #

• 把A项目中依赖B的版本号更新为刚发布的B的新版本。
• 对A进行完整的集成测试，确保A和新的B版本兼容（毕竟B有变更，可能影响A的功能逻辑）。
• 根据A的变更情况（这里属于依赖升级带来的间接变更，若未修改A自身代码，版本号一般升小版本即可，比如从2.0.0升到2.0.1），完成测试后打包发布A的新版本。

4. 同步版本变更信息 #

• 如果有其他项目依赖A或B，记得通知相关开发者可以升级到新版本；如果是内部团队项目，也要把版本变更记录同步到团队文档或版本日志中，避免版本混乱。

模块发布的核心原则是只发布有实际变更的模块：

• C没有任何代码或依赖变动，发布它完全是冗余操作，不仅浪费时间，还可能引入不必要的版本混乱（比如其他依赖C的项目误升级到无意义的新版本）。
• B依赖的是C的特定稳定版本，只要这个版本没有问题，就不需要替换它——依赖关系的稳定性是多模块项目版本管理的关键之一。

内容的提问来源于stack exchange，提问作者JF Meier