Semantic Versioning 2.0.0
官网

给出一个版本号MAJOR.MINOR.PATCH，增加如下：

• MAJOR version 进行不兼容的API更改时
• MINOR version 当您以向后兼容的方式添加功能时
• PATCH version 当您进行向后兼容的错误修复时

预发布(pre-release )和构建元数据的附加标签可以作为MAJOR.MINOR.PATCH格式的扩展。

语义版本控制规范(SemVer)

本文档中的关键词“MUST”，“MUST NOT”，“REQUIRED”，“SHALL”，“SHALL NOT”，“SHOULD”，“SHOULD NOT”，“RECOMMENDED”，“MAY”和“OPTIONAL”的解释与RFC 2119中描述的一致。

1. 使用语义版本控制的软件必须(MUST)声明一个公共API。这个API可以在代码本身中声明，也可以严格存在于文档中。无论如何，它都应该(SHOULD )是精确和全面的。
2. 正常的版本号必须采用X.Y.Z的形式，其中X, Y和Z是非负整数，并且不得包含前导零。X表示主版本，Y表示次版本，Z表示补丁版本。每个元素必须以数字形式递增。例如:1.9.0 -> 1.10.0 -> 1.11.0。
3. 一旦一个版本化的包被发布，该版本的内容绝对不能被修改。任何修改必须作为新版本发布。
4. 主版本0 (0.y.z)用于初始开发。任何事情都可能随时发生变化。公共API不应该被认为是稳定的。
5. 版本1.0.0定义了公共API。版本号在此版本发布后增加的方式取决于此公共API及其变化方式。
6. 如果只引入向后兼容的错误修复，则补丁版本Z (x.y.Z | x > 0)必须递增。错误修复被定义为修复不正确行为的内部更改。
7. 如果向公共API引入新的向后兼容功能，则必须增加次版本Y (x.Y.z | x > 0)。如果任何公共API功能被标记为弃用，它必须递增。如果在私有代码中引入了实质性的新功能或改进，则可能会增加。它可能包括补丁级别的更改。当次要版本增加时，补丁版本必须重置为0。
8. 如果向公共API引入任何向后不兼容的更改，则主版本X (X.y.z | X > 0)必须递增。它还可能包括次要和补丁级别的更改。当主版本增加时，补丁和次要版本必须重置为0。
9. 预发布(pre-release)版本可以通过在补丁版本后面立即添加连字符和一系列点分隔的标识符来表示。标识符必须只包含ASCII字母数字和连字符[0-9A-Za-z-]。标识符不能为空。数字标识符不能包含前导零。预发布版本的优先级低于相关的正常版本。预发布版本表示该版本不稳定，可能无法满足其关联的正常版本所表示的预期兼容性需求。例如:1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92, 1.0.0-x-y-z.--.
10. 构建元数据(Build metadata)可以通过在补丁或预发布版本后立即添加加号和一系列点分隔的标识符来表示。标识符必须只包含ASCII字母数字和连字符[0-9A-Za-z-]。标识符不能为空。在确定版本优先级时，必须忽略构建元数据。因此，只有构建元数据不同的两个版本具有相同的优先级。例如:1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3----117B344092BD.
11. 优先级指的是版本在排序时如何相互比较。
    1 优先级必须通过按顺序将版本划分为主、次、补丁和预发布标识符来计算(构建元数据不计入优先级)。
    2 优先级由从左到右比较每个标识符时的第一个差异决定，如下所示:主要、次要和补丁版本总是用数字来比较。
    例如: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1
3 当major, minor和patch相等时，预发布版本的优先级低于正常版本:
    例如: 1.0.0-alpha < 1.0.0
4 具有相同主、次和补丁版本的两个预发布版本的优先级必须通过从左到右比较每个点分隔标识符来确定，直到发现如下差异:
    a. 仅由数字组成的标识符用数字进行比较。
    b.带有字母或连字符的标识符按ASCII排序顺序进行词法比较。
    c.数字标识符的优先级总是低于非数字标识符。
    d.如果前面所有的标识符相等，那么较大的预发布字段集比较小的字段集具有更高的优先级。
    例如: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0