如何使用mvn versions:update-parent强制指定任意父版本？

我之前也碰到过一模一样的场景——父POM项目A要先发布新版本，子项目B再跟进升级父依赖版本，这里分享几个能让流程顺畅的实操方法：

1. 先稳妥升级并发布父项目A #

• 第一步：在项目A的根目录，用Maven命令批量更新自身版本（假设要升级到1.2.0）：

  mvn versions:set -DnewVersion=1.2.0
  

  这个命令会自动替换项目A所有模块里的版本号，包括根pom的<version>字段，比手动修改高效不易错。
• 第二步：本地执行mvn clean install验证构建无问题，然后提交代码并触发项目A的发布流程，务必确保新版本的父POM已经推送到你们的Maven仓库（不管是内部私服还是公共仓库）。

2. 同步子项目B的父依赖版本 #

等项目A的新版本在仓库可用后，再处理项目B：

• 方法一：手动修改B的pom.xml里的<parent>块，把<version>字段改成A的新版本1.2.0：

  <parent>
    <groupId>com.yourcompany</groupId>
    <artifactId>project-a</artifactId>
    <version>1.2.0</version>
  </parent>
  

• 方法二：用Maven命令自动更新父依赖版本（适合多模块的项目B）：

  mvn versions:update-parent -DparentVersion=[1.2.0]
  

  如果你们的发布流程只用正式版本，可以加上-DallowSnapshots=false避免意外引用快照版本。
• 第三步：本地执行mvn clean install验证构建正常，确认能拉取到A的新版本依赖，再提交代码触发项目B的发布。

3. 避免踩坑的小技巧 #

• 绝对不要跳过父POM发布直接改子项目：如果A的新版本还没推到仓库，B本地构建会报错找不到父依赖——哪怕你把A的新版本安装到本地仓库（mvn install），也只适合本地测试，正式发布必须等A的版本在仓库可用。
• 谨慎使用版本范围：虽然可以给父依赖设版本范围（比如[1.1.0,1.3.0)），但这会导致构建版本不稳定，发布流程里尽量用固定版本，避免后续构建意外拉到未预期的新版本。
• 自动化脚本提效：如果你们经常要做这种版本同步，可以写个简单的shell脚本，先触发A的版本更新和发布，等发布完成后自动更新B的父版本并提交，减少手动操作的失误。

补充：如果发布流程允许，其实也可以先在本地同时更新A和B的版本，把A安装到本地仓库后先构建B，再发布A最后发布B，但根据你提到的流程约束（必须先改A再改B），上面的步骤更贴合你的需求。

内容的提问来源于stack exchange，提问作者Frédéric Donckels