我所有的项目，库或应用程序均在Maven Central上发布。 如果您不知道它是如何工作的，我会简单地告诉您：这是一场噩梦 。
当然，我不得不经历这些步骤一两次，但后来我意识到我最好还是让Rultor为我完成所有工作，因为我已经在使用它了，以使master分支保持只读并自动进行合并请求的数量。 这是如何优雅地实现发布过程自动化的方法–我执行了几乎相同的步骤。
汤姆和杰瑞（Tom＆Jerry）–老鼠清洁，威廉·汉娜（William Hanna）和约瑟夫·巴贝拉（Joseph Barbera）
现在，在版本控制方面，我使用经典的xyz方案：递增z表示发行版主要包含错误修正和小功能，递增y表示发行版包含某些大功能，而递增x表示发行版不向后兼容以前的。 自然，我希望存储库中的坐标能够自动更新（例如，如果新版本为0.0.3 ，则pom.xml的版本0.0.3为0.0.4-SNAPSHOT ，这是下一个开发迭代）。
尽管Rultor可以构建工件并将其发送到Maven Central，还可以在Github存储库中创建标签（“发行版”），但它对实际的版本控制规则绝对一无所知。 这意味着pom.xml中的版本以及指向工件的任何其他链接或坐标都不会更新。
经过几个小时的工作，一次成功地使Rultor崩溃了（很抱歉），我想到了这个脚本 ，我在所有项目中都使用了该脚本 。 它做了一些重要的事情：
- 它执行实际的mvn构建，尤其是使用
release配置文件。 实际上，这是将工件发送到Maven Central的步骤。 - 它在
pom.xml设置了下一个开发版本 - 它更新README.md中指定的
<dependency> - 它更新到胖子罐的链接，通常在下面将其指定。
这样，我可以确保在需要的地方自动引用了最新版本，并且没有陈旧/旧的链接。 编写此脚本最多的时间是弄清楚rultor如何准确构建我的发行版（在哪个分支上）以及如何/何时提交并将更改推送到Github。 之后，我只是在rcfg.sh文件指定为“发布脚本”，它就像一个超级按钮一样工作。
翻译自: https://www.javacodegeeks.com/2018/10/project-versioning-rultor.html