Golang语言中的Go Mod的版本和伪版本详解

前言

今天讲一下 Go Module 中软件包的版本和伪版本的内容，因为这是一个理想很丰满、现实很骨感的故事。

Module 的版本

关于 Go Module 依赖包的软件版本，这块知识就很中规中矩啦，大部分资料里也都有提及。

Go Modules模块的版本格式为“主版本号.次版本号.修订号”，版本号的递增规则如下：

v1.26.0
 | |  |_ _  修订号
 | | 
 | |_ _ _ _ 次版本号
 |
 |_ _ _ _ _ 主版本号

1. 主版本号：当你做了不兼容的更新时变更主版本号。
2. 次版本号：当你做了向下兼容的功能性更新时更改次版本号。
3. 修订号： 当你做了向下兼容的问题补丁修正时更改修订号。

不过当你在真正在项目里使用 Go Module 管理项目依赖的时候，尤其是你们公司内部的私有依赖模式时，你就会发现事情完全没有这么简单。

多数情况下，go.mod 文件里会有一堆依赖他们的版本会是酱婶儿的：

golang.org/x/lint v0.0.0-20200302205851-738671d3881b 
...
code.xxx.com/libs/xyz v1.0.10-0.20220805095508-6c1f3628ef7a

这个就是我们接下来要说的伪版本了。

Module 的伪版本

Pseudo

v0.0.0

golang.org/x/lint v0.0.0-20200302205851-738671d3881b

go getgo.mod

v0.0.0

code.xxx.com/libs/xyz v1.0.10-0.20220805095508-6c1f3628ef7a

go get  模块名@CommitHash

go get code.xxx.com/libs/xyz@6c1f3628ef7a

v1.0.10v1.0.9v1.0.9

这里再放一个伪版本各部分的说明图给大家，方便理解记忆。

关于模块的伪版本，虽然我们掌握了它的生成规则，但使用的时候一定不要自己在 go.mod 文件里去编辑，而是使用上面举例的go get 命令，让 Go Module 自己生成模块的伪版本。

伪版本的乱象

针对在测试、开发阶段的依赖模块，因为不能在主干分支上打标签，我看到网上不少资料推荐以这种方式设置版本：

// 在测试分支上打标签
v1.2.30-test
// 在仿真分支上打标签
v1.2.30-pre

masterv1.2.30go.mod

不过实际我看下来，更多的是使用伪版本的居多，而且很多线上项目在 go.mod 文件里直接就是引用的这些伪版本的模块。

这些问题咋一看起来没有什么事儿，但是我前段时间改了个被降本提效的团队的项目，里面就很多这种使用依赖的伪版本，更坑的是他们没把这个版本里的代码合并到主干，导致我更新了一个新版本，测试的时候，报了一个类似这样的错。

package provided […] but not at required version

Go Module 告诉我某个包在原来的版本的模块里，不在你声明的版本里… 。

总结

今天给大家介绍了 Go Module 关于模块版本管理的几个小知识，也说了下在开发模块时的一些乱象，咱们最好还是遵守上面说的，测试阶段在测试分支打标签，发布的时候一定要和到主干上打正式标签，项目不要还依赖着模块的伪版本呢就上线了，发布前检查一下 go.mod 及时更改过来，就不会像我这大冤种，天天给前人填坑啦。

互联网公司风风火火，人来的快走的也快，这些都是团队没有好的规范造成的，打工人也只能接受，但是我们一定要了解一些东西到底怎么用才是正确，怎么建立起良好的规范，才不会出现这种多人协作时一团乱的问题。

关于 Go 开发项目，实战方面更多的内容，我理了一本《Go 开发参考书》 收集了80多条开发实践。去公众号「网管叨bi叨」回复【gocookbook】即刻领取

本篇文章来至：IT社区