我需要支持两个版本，但库版本存在一些差异，因此我制作了两个版本配置文件，并且工作正常，但是现在在准备发行版时出现版本问题。
我使用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，然后仅增加最后一个数字，无论是修复错误还是添加新功能。
我感觉自己正在做一些反模式的工作，有人可以给我一些建议吗？
PS 我已经大量修改了2.x版本，因此无法为2.x和1.x版本使用单独的分支，除非有机会将版本切换到3.0
更新
我想我不能简单讲这个故事，所以我们开始吧。
在我的项目中，我曾经有ojdbc6和aqapi个jars（oracle库），我的应用程序正在java 7数据库的Apache ServiceMix 5和oracle 11上工作。但是随后某些客户端更新到oracle 12，因此我需要新的库，但它们仅适用于java 8，但是我作为ServiceMix 5的一部分使用的ActiveMQ不适用于java 8 。因此，我更新为servicemix 7，并且在某些机会后，它可以正常工作。因此，构建配置文件中其余的差异是servicemix提供的库的版本（我想这里完整的列表是多余的）。
最后，尽管新的jdbc驱动程序与旧数据库完全兼容（虽然不确定aqapi和ActiveMQ的客户端，但它们也应该兼容），但我不能强迫每个客户端进行更新和重新安装java \ servicemix在同一时间，但我仍然希望能够为所有人修复\添加内容。
因此，我至少现在需要为不同版本的servicemix支持两个构建（这是一个临时解决方案，但是正如谚语所说：没有什么比临时更持久了，所以我想以最正确的方式实现它可能）
P.S。 我决定在VCS中创建配置文件而不是单独的早午餐，因为它看起来似乎更容易解决，但是就版本问题而言，它并不令人满意。
答案 0 :(得分：0)
因此，正如@Software工程师所说，在考虑了原因并编写了更新后，我意识到它不是多配置文件问题，这纯粹是版本问题，如果我在VCS中进行早午餐，则完全相同。
所以最终我还是决定制作1.x.x和2.x.x版本，尽管这些更改并不是“破坏性的”，但是它们并不完全向后兼容（即使新版本也可以使用对于旧数据库，它仍然需要新的servicemix）。
这种多配置文件的解决方法看起来并不漂亮，但是我把它留在了那里，它使我可以一次构建两个版本（我在第一次构建后使用mvn versions:set -DnewVersion命令），而且我不需要支持这样可以进行两次早午餐，这样可以节省一些时间。