在我读完 this article 之后和另一个，我发现版本控制是程序员的决定，所以我相信 CI 系统无法理解这个包的版本(CI 系统无法理解pulled commit 是一个补丁，一个新特性)。
但是，程序员无法知道如何将补丁(错误、功能等)链接到发布版本编号标识。
根据语义版本控制:
- 当您只发布错误修复等时，增加补丁版本(例如从 2.3.4 到 2.3.5)
- 在添加新功能时增加次要版本(例如从 1.3.2 到 1.4.0)
- 在引入重大更改时增加主要版本(例如从 3.2.9 到 4.0.0)
我的语义版本将遵循下一个模式:1.2.3+7489ab44d3，其中 1 是主要版本号，2 是次要版本号，3 是补丁或错误号。那么 +7489ab44d3 将是 CI 系统上构建的作业标识。
因此，此模式的第一部分取决于人脑，最后一部分在 CI 系统下。
我也读过，可以使用问题跟踪器系统来根据某种信息整理每个问题并将其提供给 CI 系统。
为了实现这一目标，提供自动化的最佳方式是什么？
最佳答案
我们正在使用插件来做到这一点。
https://wiki.jenkins-ci.org/display/JENKINS/Version+Number+Plugin
我们知道基于分支名称的版本是什么，并根据它生成适当的内部版本号。
它是构建过程中的一个单独任务，您可以使用多个系统和插件来实现它。
关于git - 语义版本控制自动化，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/34705353/