我需要支持两个版本，但库版本存在一些差异，因此我制作了两个版本配置文件，并且工作正常，但是现在在准备发行版时出现版本问题。
我使用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版本建立单独的分支。 ]
upd
我想我不能简单讲这个故事，所以我们开始吧。
[在我的项目中，我曾经拥有ojdbc6和aqapi jars（Oracle库），我的应用程序正在java 7和Apache ServiceMix 5数据库上运行。但是随后某些客户端更新到oracle 12，因此我需要新的库，但它们仅适用于oracle 11，但是我用作java 8的一部分的ActiveMQ不适用于ServiceMix 5。因此，我更新为java 8，并在某些机会后正常运行。因此，构建配置文件中其余的差异是servicemix提供的库的版本（我想这里完整的列表是多余的）。
最后，尽管事实是新的jdbc驱动程序与旧数据库完全兼容（不确定aqapi和ActiveMQ的客户端，但它们也应该兼容），我不能强迫每个客户端更新并重新安装Java \ servicemix在同一时间，但我仍然想为所有这些人修复/添加内容。
因此，至少目前，我需要为不同版本的Servicemix支持两个构建（这是一个临时解决方案，但正如谚语所说：没有什么比临时更持久了，所以我想以最正确的方式实现它）
P.S。我决定在VCS中创建配置文件而不是单独的早午餐，因为它看起来似乎更容易解决，但是就版本问题而言，它并不令人满意。
因此，如@Software工程师所说，在考虑了原因并编写了更新后，我意识到它不是多配置文件问题，这纯粹是版本问题，如果我在VCS中进行早午餐，则完全一样。
所以最后我决定制作servicemix 7和1.x.x版本，尽管更改不是那么“令人吃惊”，但它们并不完全向后兼容（即使新版本仍然可以与旧数据库一起使用，需要新的servicemix）。
这种多配置文件的解决方法看起来并不漂亮，但是我把它留在了那里，它使我可以一次构建两个版本（我在第一次构建后使用2.x.x命令），而我不需要为此提供两个早午餐方式，这样可以节省一些时间。