语义版本控制是否允许版本号包含4个组件？

我所看到的所有语义版本控制示例都显示了3个使用中的组件。不超过2个句点字符。在$DAYJOB，我们在发行版号中使用4个组件：

5.0.1.2

语义版本允许吗？

作为一个更高层次且更具争议性的附带问题，这真的很重要吗？我开始认为实施语义版本控制可能是一个好主意，但最终像PCI这样的实体会覆盖它。

我应该在我的PCI评论中弄清楚。问题在于，当主要和次要组件发生更改时，审核及其成本会受到影响，而这不一定是真正的新功能。例如，如果引入了与付款相关的功能，我们将为PCI分配次要数字。但是，如果我们在gui中添加了与某物相关的全新功能，则不会。仅补丁程序更改。因此，在这种情况下，作为开发人员，我们实际上没有发言权，因为其他人会做出这些决定。

听起来您正在为了避免过程开销/审计而绕过常规约定。那...让我感到震惊。

您正在执行的操作是有效地故意故意增加了一个额外的版本号（您的次要PCI数字），以便将功能/次要版本号移回某个位置，从而不再触发内部审核标准。

无论如何，进入关于语义版本控制的问题时，语义版本控制规范指出：

给定版本号MAJOR.MINOR.PATCH，增加：

• 当您进行不兼容的API更改时的主要版本，
• 以向后兼容的方式添加功能时的MINOR版本，并且
• 进行向后兼容的错误修复时的PATCH版本。
• 可以使用预发布和构建元数据的其他标签作为MAJOR.MINOR.PATCH格式的扩展。

强调我的。

所以问题是，您是否将第四个字符用于预发布/构建元数据？还是基本上是您要发布的另一个版本指示？

如果为“是”，则语义版本控制规范会允许这样做。如果为“否”，那么从技术上讲您不会遵循语义版本控制。

作为一个更高层次且更具争议性的附带问题，这真的很重要吗？

是否要严格遵循它是您和您的团队必须做出的决定。语义版本控制的目的是帮助实现API兼容性：

错误修复不影响API会增加补丁程序版本，向后兼容的API添加/更改会增加次要版本，而向后不兼容的API更改会增加主版本。

我将此系统称为“语义版本控制”。在这种方案下，版本号及其更改方式传达了有关底层代码以及从一个版本修改到另一个版本的含义。

这是一个系统，可以帮助您在版本控制影响API的下游用户时更加清楚。

只要您的API同样清晰明了，选择哪种方法就没什么大不了的。语义版本控制恰好很简单，例如，如果我使用的是3.4.2，并且需要升级到3.4.10，我知道我可以做到而不会破坏任何内容。如果新版本是3.5.1，我知道它是向后兼容的。我知道4.0.1版将是一个重大更改。

这就是版本号含义的全部内容。

@enderland基本上是。主要（PCI）。次要（PCI）。功能.HOTFIX + BUILD。基本上，我们只允许在不涉及PCI（以及公司的PCI霸主）的情况下更改第三和第四部分。在我看来，这有点做作，我不确定它们在管理版本号方面是否合理，但我对PCI和审核过程的了解还不够多，所以不能这么说。

好的，这很好。您的系统可以为您服务并满足您的需求。这就是版本控制的重点。

如果您的API是私有的（仅面向内部），那么只要您和使用它的每个人都可以理解，版本的大小就无关紧要。当您有许多其他API使用者需要了解“此版本的含义是什么”时，标准格式的版本管理就很重要。

具有任意版本控制系统会使使用其他系统的人感到困惑，例如语义版本控制。但是，如果没有人真正在使用您的版本控制系统，除了创建它的人之外，这没有关系。

在当前版本的语义版本控制（2.0.0）中。要求将版本定义为XYZ形式，其中X，Y和Z是不包含前导0的非负整数：

普通版本号必须采用XYZ格式，其中X，Y和Z为非负整数，并且不得包含前导零。X是主要版本，Y是次要版本，Z是修补程序版本。每个元素必须按数字增加。例如：1.9.0-> 1.10.0-> 1.11.0。

但是，允许添加元数据的功能有：

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

但是，需要注意的重要一点是，语义版本控制专门用于声明公共API的软件：

使用语义版本控制的软件必须声明一个公共API。该API可以在代码本身中声明，也可以严格存在于文档中。不管这样做，它应该准确而全面。

这倾向于支持库或服务的开发，而不是在应用程序级别上。

要考虑的重要事项是您的版本号对内部和外部使用都意味着什么。版本只是标识符，使您可以在两个不同的时间点谈论软件上的差异。语义版本控制是一种围绕规则进行设置的方法，因此，如果您知道应用程序正在使用语义版本控制，则可以更轻松地确定更新软件包所需的工作水平。遵循通用标准可能会很好，但是如果出于某种原因您不能这样做，则为用户记录规则也就足够了。