长期以来，我们所有人都习惯于
Maven提供的版本控制和依赖管理。 Maven诞生于该项目的日常工作最为艰巨的时候，当它被认为是每年至少发布两次的正常情况时，
詹金斯便被称为
哈德逊 ，而且树木很大……
Maven带给开发人员的想法非常流行，并且很快就变得流行：定义一个标准的工作流项目，一个标准的目录模型等等，这早已被视为理所当然。
作为一项创新，maven引入了标准版本控制系统。 该版本存储在项目文件中，并在我们发布新版本时进行更改。 在一个并非所有人都能做到的壮举分支及其合并的世界中，这种方法非常普遍。
所有这些都极大地简化了开发，新项目的开始，项目开发人员的介绍，版本的发布和依赖管理。
但是，世界并没有停滞不前，尽管事实上由maven实施的许多想法仍然存在并且从一个项目转移到另一个项目，但是maven的版本化已成为问题，而不是优势。
接下来，我们将努力使世界变得更好，并简化我们的生活。
免责声明我假设读者熟悉Java，Maven，开发生命周期和CI / CD配置，并且理解为什么他需要所有这些甚至是忍者 。
在现代现实中，考虑每周甚至每天发布多个版本（如果不是正常的话）就是目标。 并且，在这种情况下，将版本存储在项目文件中会导致非常大的开销。
每个版本都会导致对存储库的两次提交，因此，随着项目的积极开发和发布，此类技术提交比有用的提交要多。 该项目的历史乱七八糟，难以理解。
而且，这种方法会导致信息重复：不仅将版本存储在项目文件中，而且还以存储库标签的形式存储，已成为一种习惯。
另外，出现了安全性问题：当您有一个大项目时，构建计算机仅需要对其进行访问。 当有很多项目时，必须访问许多项目，我们要么创建一个具有所有拥有写入权限的项目的超级用户权限，要么增加了管理大量权限狭窄的用户的负担，但仍然具有写入存储库的权限，并且通常情况下，无需提交请求和审查即可提交给主服务器的权利。
当将Maven与发布插件一起使用时，会出现另一个有趣的功能：不能使用与原始版本相同的命令集来执行重建。
也许所有这些问题对于某人来说似乎都是牵强附会的，但是随着项目数量的增加或减少，管理和配置CI / CD会变成一个极其令人不愉快且令人困惑的过程。
现在问题已经可见，让我们尝试解决问题，以免更改工具，流程以及总体上这样的设置，以便以某种方式解决问题本身。
需要什么：
- 版本作为存储库标签存储一次
- 可以重建任何发行版，因此步骤集应与新发行版的步骤相同
- 无权写入存储库
- 我们仍然使用Maven作为项目经理
假设CI / CD将为我们获得标签并签出项目。
假设为我们提供的标签已用CI / CD填充到环境变量RELEASE_TAG中，那么，要发布该发行版，我们必须执行以下命令：
mvn -B versions:set -DnewVersion=$RELEASE_TAG (1) mvn -B deploy (2)
1-更新项目及其模块的pom文件中的版本
2-构建，如果项目配置正确，则将工件上传到存储库
不要忘记设置
-B标志，否则执行日志将变成南瓜。
重要：为了避免混淆并清楚地显示程序集的来源和位置，您需要以抽象的方式安装项目版本，例如DEVELOPMENT-SNAPSHOT。 您可以使用相同的命令：version：set。 该操作是一次性的，因为我们不再将项目的版本存储在文件中。
作为更改的结果，您可以从pom文件中删除maven-release-plugin和scm块配置。
»的缺点：
如果您在某处使用SNAPSHOT版本，则可能会开始混乱，现在所有SNAPSHOT版本看起来都一样。 也许这种发布项目的方式不适合您。
从同一提交但使用不同标签收集的工件似乎可能是相同的，但不幸的是，事实并非如此。 我们仍然在文件中公开版本，因此，收集的软件包将有所不同。
»来自专业人士：
- 满足所有要求，甚至更多！
- 版本仅存储在项目标签中
- 新版本的组装和旧版本的重建通过与原始版本相同的命令集执行
- 无需权利参与该项目
- 工具箱保持不变
- 好处：简化了项目配置
因此，两条线再次拯救了世界。
就这样，谢谢您的关注！