Trunk-Based Development(TBD)多版本管理及版本更新位置咨询

一、pom.xml版本更新的最优处理方式 #

核心原则：主干始终使用快照版本，正式版本仅在发布/维护分支中更新，彻底隔离主干版本变更与发布操作：

• 日常开发阶段：主干的pom.xml保持x.y.z-SNAPSHOT格式（比如当前开发1.1.x系列时，主干版本为1.1.0-SNAPSHOT），所有开发提交都基于这个快照版本，不涉及正式版本变更。
• 正式发布流程：
  1. 从主干拉出发布分支（如release/1.1.0），在该分支内将版本更新为正式版1.1.0，完成测试、发布后打标签v1.1.0。
  2. 将发布分支合并回主干，同时在主干中把版本更新为下一个快照版本（如1.1.1-SNAPSHOT）——这个合并仅做一次版本跳变，不会和日常bug修复的cherry-pick操作冲突。
• 老版本bug修复流程：
  1. 从目标版本的发布标签（如v1.0.2）拉出维护分支（hotfix/1.0.3），在分支内将版本改为1.0.3-SNAPSHOT进行修复。
  2. 修复完成后，在维护分支中更新为正式版1.0.3，发布并打标签v1.0.3。
  3. 仅将bug修复的业务代码（排除pom.xml版本变更）cherry-pick回主干，避免版本号回退的误导性显示。

二、多活跃版本的冲突与混淆规避方案 #

通过明确分支职责、隔离版本线，彻底解决跨版本发布时的主干版本回退问题：

• 分支职责划分：
  • 主干：仅承载当前活跃的下一个大版本开发（比如1.1.x），版本号始终单向递增，绝不回退。
  • 发布分支：临时分支，仅用于对应版本的发布准备，发布完成后可保留或归档，不参与日常开发。
  • 维护分支：从已发布版本的标签创建，专门维护老版本（如1.0.x），所有老版本的修复、发布操作都在该分支内完成，与主干完全隔离。
• 具体场景处理（发布1.1.0后再发布1.0.3）：
  1. 1.1.0发布完成后，主干版本已更新为1.1.1-SNAPSHOT，且打有v1.1.0标签。
  2. 启动1.0.3维护时，从v1.0.2标签拉出hotfix/1.0.3分支，在该分支内完成bug修复，更新版本为1.0.3后发布，打v1.0.3标签。
  3. 将bug修复代码（不含pom.xml版本变更）cherry-pick回主干，此时主干版本仍保持1.1.1-SNAPSHOT，不会出现版本回退的视觉误导。
• 辅助优化：
  • 版本标签规范：所有正式发布版本必须打带前缀的标签（如v1.0.3），通过标签快速定位各版本的代码基线。
  • 自动化版本管理：用CI/CD脚本自动完成发布/维护分支的版本替换，减少手动修改pom.xml的操作，进一步降低冲突概率。

内容的提问来源于stack exchange，提问作者Baksa Zoltán