【发布时间】：2019-12-11 15:09:05
【问题描述】：
我需要支持两个在库版本中存在一些差异的构建，所以我制作了两个构建配置文件，这工作正常，但现在我在准备发布时遇到了版本控制问题。
我使用major.minor.revision-qualifier 版本控制架构，其中：
-
major- 重大变化 -
minor- 向后兼容的更改（新功能） -
revision- 一个错误修复 -
qualifier- 我现在使用的唯一限定符是SNAPSHOT来标记未发布的版本。
但是由于现在我有两个版本，我需要添加一些限定符来发布版本，例如1.8.0-v1 和 1.8.0-v2，但是我将无法拥有两个 SNAPSHOT 版本。或者我需要打破关于major\minor 版本使用的“规则”并创建两个“分支”，例如发布1.8.0 和1.9.0，然后无论是修复错误还是添加新功能，都只增加最后一个数字。
我觉得我在做一些反模式，有人可以给我一些建议吗？
P.S. 我已经对 2.x 版本进行了大量修改，所以我不能有单独的“分支”作为 2.x 和 1.x 版本，除非我将此新版本更改为3.0
更新
我想我不能让这个故事简短，所以我们开始吧。
在我的项目中，我曾经拥有ojdbc6 和aqapi jar（oracle 库），我的应用程序正在使用oracle 11 数据库处理java 7 和Apache ServiceMix 5。但是后来一些客户端更新到 oracle 12，我需要新的库，但它们只适用于java 8，但我作为ServiceMix 5 的一部分使用的 ActiveMQ 不适用于java 8。所以我更新到servicemix 7 并且经过一些机会它工作正常。所以构建配置文件的其余差异是 servicemix 提供的库的版本（我猜这里完整的列表是多余的）。
最后，尽管新的 jdbc 驱动程序与旧数据库完全兼容（不完全确定 aqapi 和 ActiveMQ 的客户端，但它们应该也兼容），但我不能强制每个客户端更新和重新安装java\servicemix 同时，但我仍然希望能够为所有这些修复\添加东西。
所以我需要为不同版本的 servicemix 支持两个构建，至少现在（这是一个临时解决方案，但正如谚语所说：没有什么比临时更永久的了，所以我想以最正确的方式实现它可能）
附言 我决定在 VCS 中制作配置文件而不是单独的 brunch，因为它看起来更简单的解决方案，但在版本控制问题方面并没有什么问题。
【问题讨论】：
-
我猜构建配置文件不是最好的方法。两个版本的项目有什么区别，为什么会存在？
-
配置文件只是错误的方法，因为您已经意识到发布时会遇到问题。问题是：为什么需要不同的库/版本？如果是这样，请制作具有不同部门/版本的单独模块并一次性发布......并保持语义版本控制......
-
我猜你正在写这个问题，因为你第二次添加 -v1 和 -v2 你意识到你做错了什么。回复@JFMeier 评论中的问题，您可能会在这样做时看到答案。
标签： java maven versioning