并行开发两个产品版本时的程序集版本控制问题

我们的软件正式版本1.3正在收尾，同时团队并行开发1.4版本。测试阶段发布客户预发布版本时，采用语义化版本控制管理程序集：程序集有小变更时，升级版本号的第二个组件，确保安装程序能识别出需要替换的程序集。

现有程序集Example Assembly.dll当前版本为3.0.0.0，期间出现了版本冲突问题：

• 1.4的首个测试版本中，该程序集做了小变更，版本升至3.1.0.0
• 随后在1.3的第25个测试版本中，该程序集也做了小变更，版本同样升至3.1.0.0
  这导致出现两个内容不同但版本号完全一致的程序集，用户从1.3测试版升级到1.4测试版时，Example Assembly.dll不会被正确替换。

当前的疑问是：在1.4的下一个测试版本中，无论该程序集是否有小变更、构建/修订变更，只要无重大变更，就将版本升至3.2.0.0，这种做法是否正确？

问题过程明细 #

结论与分析 #

这种做法无法从根源解决问题，只是暂时规避了单次冲突，但后续1.3的测试版本仍可能跟进升级次版本号，再次出现同版本号不同内容的情况，导致升级失败。

核心问题在于并行开发的两个分支（1.3和1.4）独立维护程序集版本号，没有关联隔离机制。更合理的解决思路包括：

• 为不同产品版本的程序集版本号引入分支标识，比如在修订号或构建号中加入产品版本标记（如1.3分支用3.1.25.0，1.4分支用3.1.0.1），确保分支间版本号唯一
• 合并1.3的变更到1.4时，强制将1.4分支的程序集版本号升级到比1.3当前版本更高的层级，同时后续1.3的小变更仅升级修订号而非次版本号，避免次版本号冲突
• 采用版本号与分支绑定的策略：1.3分支的程序集次版本号固定为x.y.*，1.4分支固定为x.(y+1).*，从根源上隔离两个分支的版本号空间

内容的提问来源于stack exchange，提问作者Matt Arnold