为什么build.number是语义版本控制的“滥用”？

我解释提出了构建系统（摇篮/ Artifactory的/詹金斯/厨师），以我们的高级建筑师之一，他所提出的意见，我认为我的那种不同意，但我没有足够的经验，真正权衡上。

该项目构建了一个Java库（JAR）作为工件，供其他团队重用。对于版本控制，我想使用以下语义方法：

<major>.<minor>.<patch>

其中patch指示错误/紧急修复，minor指示向后兼容的发行版，并major指示API的大规模重构和/或向后不兼容的更改。

就交付而言，这就是我想要的：开发人员提交一些代码；这将触发构建到QA / TEST环境。一些测试已经运行（一些自动化，一些手动）。如果所有测试均通过，则生产版本会将JAR发布到我们的内部仓库中。至此，应该正确地对JAR进行版本控制，我的想法是使用build.numberCI工具自动生成并提供的JAR 作为补丁号。

因此，版本控制实际上是：

<major>.<minor>.<build.number>

同样，build.numberCI工具在哪里提供。

架构师对此表示否认，称使用CI版本号是语义版本控制的“滥用”。

我的问题是：这是正确的吗？如果正确，为什么？如果没有，为什么不呢？

您的内部版本号不会重置为0，当次要和主要版本增加时，这会违反规范的第7和8节：

如果将新的向后兼容功能引入了公共API，则必须增加次要版本Y（xYz | x> 0）。如果任何公共API功能标记为已弃用，则必须递增。如果在私有代码中引入了实质性的新功能或改进，则可以增加它。它可能包括补丁级别的改变。当次要版本增加时，补丁版本必须重置为0。

如果向公共API引入了任何向后不兼容的更改，则必须增加主要版本X（Xyz | X> 0）。它可能包括次要级别和补丁级别更改。当主要版本增加时，补丁和次要版本必须重置为0。

因此，必须手动提供版本号（主要，次要，补丁），因为它们用于告诉您的用户某个地方的更改，而无需他们查看变更日志或其他文档。

如果要包括内部版本号，则可以在+第10节之后附加它们：

可以通过在补丁或预发行版本之后立即添加加号和一系列由点分隔的标识符来表示构建元数据。标识符只能包含ASCII字母数字和连字符[0-9A-Za-z-]。标识符不得为空。确定版本优先级时，应忽略构建元数据。因此，只有版本元数据不同的两个版本具有相同的优先级。例如：1.0.0-alpha + 001、1.0.0 + 20130313144700、1.0.0-beta + exp.sha.5114f85。

一个原因是该修补程序可能需要多个构建，因此，如果您具有版本5.7，并且想要将其修补到5.7.1，但是当您将前2个错误修复提交给CI系统后无法构建，那么您将在发布第一个补丁之前，请按照5.7.3进行操作！

答案是简单地使用4位数字（这是Microsoft系统倾向于使用的）。第四位是内部版本号，“仅供参考”。通常，人们将存储库的版本号放在那里（如果他们使用SVN或TFS或类似的东西），这真的很好，因为您可以验证用于构建二进制文件的确切提交。如果您没有这样的东西，那么CI内部版本号是一个合理的近似值（因为您希望您的CI系统可以记住内部版本号并将其与回购历史记录相关联，但是您并不依赖于CI系统会记住它们-您永远无法删除旧版本）。

需要注意的一件事是，用于版本控制的Microsoft架构使用内部编号作为内部版本号。Chrome仅使用1个数字。Ubuntu使用日期。没有“标准”可使用，只是所有数字必须递增。