本文翻译自《Module version numbering》。
目录
模块的开发人员使用模块版本号的每个部分来表示版本的稳定性和向后兼容性。对于每个新版本，模块的版本号具体反映了自上一个版本以来模块更改的性质。
当你开发使用外部模块的代码时，可以在升级时使用版本号来了解外部模块的稳定性。当你开发自己的模块时，你的版本号将向其他开发人员指示模块的稳定性和向后兼容性。
本主题描述模块版本号的含义。
另请参阅
- 当你在代码中使用外部包时，可以使用Go工具管理这些依赖关系。有关详细信息，请参见管理依赖关系。
- 如果你正在开发供其他人使用的模块，则在发布模块时使用版本号，并在其代码存储库中加标签。有关详细信息，请参见发布一个模块。
发布的模块使用语义版本号控制模型给出的版本号，如下图所示：
下表描述了版本号的各个部分如何表示模块的稳定性和向后兼容性。
| 各阶段的版本号 | 示例 | 给开发者的信息 |
| 开发过程中 | 自动给出伪版本号 v0.x.x | 表明模块仍在开发中且不稳定。此版本没有向后兼容性或稳定性保证。 |
| 主版本号(Major version) | v1.x.x | 表示向后不兼容的公共API更改。此版本不保证它将与以前的主要版本向后兼容。 |
| 次版本号(Minor version) | vx.4.x | 表示向后兼容的公共API更改。此版本保证了向后兼容性和稳定性。 |
| 补丁程序版本号(Patch version) | vx.x.1 | 表示不影响模块的公共API或其依赖关系的更改。此版本保证了向后兼容性和稳定性。 |
| 预发布版本号(Pre-release version) | vx.x.x-beta.2 | 表明这是一个预发布里程碑，例如alpha或beta。此版本没有稳定性保证。 |
开发过程中
表示该模块仍在开发中且不稳定。此版本不提供向后兼容性或稳定性保证。
版本号可以采用以下形式之一：
伪版本号(pseudo-version number)
v0.0.0-20170915032832-14c0d48ead0c
v0版本号
v0.x.x
伪版本号
当模块未在其代码存储库中打标签时，Go工具将生成一个伪版本号，供调用该模块中的函数的代码的go.mod文件使用。
注意：作为最佳实践，始终允许Go工具生成伪版本号而不是创建自己的版本号。
当使用该模块功能的代码开发人员需要针对尚未加语义版本号标签的commit进行开发时，伪版本号就很有用。
伪版本号由破折号分隔的三部分组成，如下表所示：
语法
baseVersionPrefix-timestamp-revisionIdentifier
部分
- baseVersionPrefix（vX.0.0或vX.Y.Z-0）是从之前的语义版本号标签或从vX.0.0（如果没有语义版本号标签）派生的值。
- timestamp（yymmddhhmms）是创建修订号的UTC时间。在Git中，这是提交时间，而不是作者的时间。
- revisionIdentifier（abcdefabdedef）是commit哈希值的12个字符前缀，或者在Subversion中是用0填充的修订号。
v0版本号
使用v0编号发布的模块将具有正式的语义版本号，其中包含主、次和补丁部分，以及可选的预发布标识符。
虽然v0版本可以在生产中使用，但它不能保证稳定性或向后兼容性。此外，版本v1和更高版本允许破坏v0版本的代码的向后兼容性。因此，使用v0模块中的代码的开发人员应该明白将会有不兼容的更改，直到v1发布。
预发布版本号
表明这是一个预发布里程碑，如alpha或beta。此版本没有稳定性保证。
示例
vx.x.x-beta.2
模块的开发人员可以通过添加连字符和预发布标识符，与任何major.minor.patch组合成预发布版本号。
次版本号
表明模块的公共API具有向后兼容的更改。此版本保证向后兼容性和稳定性。
示例
vx.4.x
此版本更改了模块的公共API，但并未以破坏调用代码的方式进行。这可能包括更改模块自身的依赖项或添加新函数、方法、结构体字段或类型。
换句话说，此版本可能包含新功能以进行增强，其他开发人员可能想要使用这些新功能。但是，使用以前的次版本的开发人员无需更改他们的代码。
补丁程序版本号
表示不影响模块的公共API或其依赖项的更改。此版本保证向后兼容性和稳定性。
示例
vx.x.1
增加此数字的版本更新仅适用于很小的更改，如Bug修复。使用该版本的开发人员可以安全地升级到此版本，而无需更改代码。
主版本号
表明模块的公共API有向后不兼容的更改。此版本不保证它与以前的主版本向后兼容。
示例
v1.x.x
v1或更高版本号表示模块可稳定使用（它的预发布版本除外）。
请注意，因为版本0没有稳定性或向后兼容性保证，所以将模块从v0升级到v1的开发人员负责调整破坏向后兼容性的更改。
只有在必要时，模块开发人员才应该将这个数字增加到v1以上，因为版本升级对代码使用该模块中的功能的开发人员来说意味着严重的中断。这种中断包括对公共API向后不兼容的更改，以及从该模块导入包时可能需要更新包路径。
如果主版本更新到高于v1的版本，也会有一个新的模块路径。这是因为模块路径将附加主版本号，如下例所示：
module example.com/mymodule/v2 v2.0.0主版本更新使其成为一个新模块，其历史与模块的先前版本不同。如果你正在开发要为其他人发布的模块，请参阅模块发布和版本控制工作流中的“发布破坏API的更改”。
有关模块指令的更多信息，请参阅go.mod参考。