大家好，我是煎鱼。
平时我们经常会跟踪 Go 的版本发布，看看是不是有 BUG，新特性等值得关注的东西，好吸取新的知识和技术跟进，用到自己的日常工作和系统中。
在新的特性、新的资料记录的映射上，我们也会用版本号来与之关联，这很常见。
背景
但看 Go 版本号时，会出现一个和其他软件版本不一样的神奇现象。那就是 Go 的主要版本号，居然是两位数：
说是两位数，也可以理解。结果你认真一看，会发现是主要版本和次要版本，在两位数和三位数之间横跳：
这时候就会有一个容易引起误解（理解）的事情。像是开发同学或运维同学部署开发、私有化环境时，问你用的什么版本？
可能大部分同学会直接说用 Go1.20。有了解 Go 版本号规则的人，不知道你到底说的是 Go1.20（第一个版本），还是说要求 Go1.20.x（该大版本的当前最新版本），就会造成明确混淆。
懒得纠结的，一配置，源站一拉取。就直接应用到 Go1.20 的第一个版本去了。会错过许多 Go BUG 本身的修复。（注：Docker 版本号规则与 Go 官方规则不完全一致，存在差异）
对于许多应用场景来讲，这可能影响不是特别大。但对于 Go 是一门对外开源社区运作的编程语言来讲，显然是不合适的。
要不要用 semver 做版本控制
在业内有一个管理版本号的标准：semver。版本格式："主版本号.次版本号.修订号"，版本号递增规则如下：
- 主版本号：当你做了不兼容的 API 修改，将是主版本号的破坏性变更。
- 次版本号：当你做了向下兼容的功能性新增，将是次版本的特性变更。
- 修订号：当你做了向下兼容的问题修正，将是修复的版本变更。
先行版本号及版本编译信息可以加到"主版本号.次版本号.修订号"的后面，作为延伸。并且标准的版本号必须（MUST）采用 X.Y.Z 的格式。
以往在 Go 社区很多人提了很多次，希望 Go 掰过来。用 semver 来管理社区的版本号发布，这样子最为标准化。
显然 Go 是不符合的，为什么呢？ 因为 Go 并没有采纳这个版本思路，版本号也是用 go 开头的，例如 runtime.Version() 输出的结果是：go1.20，或是 go1.20.6。
最重要的是 Go 创始人认为 semver 是理想化的，在互联网社区的路子上是行不通的，直接就拒绝了。
解决方案
经过多年的折腾，大家也认清了现实。提出了一个有意缩小变更范围的新提案《build: use a zero for third digit for major release, such as 'go1.21.0'》，争取解决背景中提到的问题。
本次仅限只做一个变动，那就是：把 ".0" 加到主版本中。例如以前是 go1.23。现在要变成 go.1.23.0。
在 Go 工具链上。例如配套的 go.mod 的 go 行，我后续也是会跟着改变的，主版本时也会多 ".0"，确保两者保持一致。
这样的妥协方案，至少可以解决解决大家对 go1.20（以该版本举例）的理解误差。明确到底是 1.20.0，还是 1.20.x 的版本。
我们也可以缓解另一派以为 go1.20.0 才是第一个 BUG 修复版本，结果没想到居然是 go1.20.1。现在会更明确和清晰些。
当然，为此会带来一些成本。例如：解析 Go 版本号的工具链和脚本的改造、文档、博客、书籍等的更新。但综合成本来看，改变的成本并不是很大。
总结
目前该提案已经完成审查和 CL，可以说很明确将会进入到 Go 后续版本的使用中。以后主版本将会是 go1.21.0 起，并补充 ".0"，而不再是以前的 go1.21，能够规避相当一部分的版本混淆问题。
这个问题，说大不大，是比较细微的变更。但在我们的日常工程构建中，是经常会遇到的。为了省事（没具体看），有的同学会在 Dockerfile 中写 go1.18，更新版本号也是写 go1.19、go1.20 等，很少会关注到后面的 BUG 修复版本，这是比较可惜的。
当然，Go 版本号的命名规则不完全统一，本身也是一个比较无奈的事。与此相类似的还有 RC 版本。
Go RC 版本目前的命名规则是：go1.20rc3。社区会建议 go1.20-rc3 的格式规范。但显然，Go 核心团队暂时没打算改。
文章持续更新，可以微信搜【脑子进煎鱼了】阅读，本文 GitHub github.com/eddycjy/blo... 已收录，学习 Go 语言可以看 Go 学习地图和路线，欢迎 Star 催更。