今天和大家聊聊GoModule中软件包的版本和伪版本，因为这是一个非常理想又很骨感的现实故事。Moduleversion关于GoModule依赖包的软件版本，这块知识还是比较满意的，大部分资料中也会提到。GoModules模块的版本格式为“主版本号.次版本号.修订号”，版本号递增规则如下：v1.26.0|||__修订号||||____次版本号||_____主要版本号主要版本号：进行不兼容更新时更改主要版本号。次版本号：当您进行向后兼容的功能更新时，更改次版本号。修订号：在进行向后兼容的错误修复时更改修订号。但是当你真正使用GoModule来管理你项目中的项目依赖，尤其是你公司内部的私有依赖模型时，你会发现事情并没有那么简单。在大多数情况下，go.mod文件中会有一堆依赖它们的版本：golang.org/x/lintv0.0.0-20200302205851-738671d3881b...code.xxx.com/libs/xyzv1。0.10-0.20220805095508-6c1f3628ef7a这个就是我们接下来要说的伪版本。Module的伪版本为什么mod文件里有那么多伪版本？这里给大家科普一下小知识。阅读技术文档时，经常会遇到伪类、伪代码、伪版本等术语。,他们基本上是在原根上加了一个Pseudo前缀，也就是说他们不是官方的类、代码、版本？（伪类好像不是这样，前端知识忘记了），而且单词开头的P不发音。。。不过好像我们读错了也没关系平时交流。毕竟很多程序员兄弟都把alter当成alert来读了，不影响我们去改MySQL表。GoModule生成的伪版本主要有两种，一种是v0.0.0开头的：golang.org/x/lintv0.0.0-20200302205851-738671d3881b这是因为代码仓库上没有标签dependentmodule，所以goget默认拉取trunk分支最新commit对应的代码，并在go.mod文件中分配模块，格式为v0.0.0-trunk分支最新commit的时间-提交哈希虚拟版本。第二种是不以v0.0.0开头的伪版本，如：code.xxx.com/libs/xyzv1.0.10-0.20220805095508-6c1f3628ef7a，一般是项目代码仓库中的tagrelease本身作为一个依赖的包版本，但我们需要稍后更新包。测试阶段，使用goget模块名@CommitHash获取官方未发布的内容：gogetcode.xxx.com/libs/xyz@6c1f3628ef7a这时候GoModule就会让我们积累在依赖的发布版本，然后生成一个伪版本，比如上面的例子，以v1.0.10开头的模块的伪版本表示该模块最后发布的版本是v1.0.9，你打开模块where看看代码仓库，那里肯定有v1.0.9标签。这里给出伪版本各部分的解释图，方便大家理解和记忆。gomod的伪版本规则关于模块的伪版本，虽然我们已经掌握了它的生成规则，但是在使用的时候一定不要在go.mod文件中编辑，而是使用上面例子中的goget命令让Go模块本身生成模块的伪版本。伪版本的乱码是针对测试和开发阶段的依赖模块，因为不能给主分支打标签，网上看到很多资料都推荐这样设置版本：//tagv1.2.30onthetestbranch-test//模拟分支上标注v1.2.30-pre等模块并通过测试，则可以在软件包的master分支上标注v1.2.30，并引用依赖模块工程中go.mod文件中声明，改成正式版。但其实我看到大部分都是使用伪版本，网上很多项目直接在go.mod文件中引用这些伪版本模块。这些问题乍一看似乎没什么，但是我前段时间换了一个团队的一个降本增效的项目，里面有很多伪版本使用依赖。代码被合并到主干中，导致我更新了一个新版本。测试的时候，报了这样的错误。packageprovided[...]butnotatrequiredversionGoModule告诉我某个包在模块的原始版本中，而不是你声明的版本中...。后来对比了很久，发现原来的版本并没有合并到主分支。在这里再次提醒大家，项目使用的内部依赖包在上线前一定要确保使用trunk上这些包的tagged版本。为什么要再次强调，一定要把最终的官方tag打在trunk分支上。。。因为如果规范不清楚，真的有大佬从feature分支上正式打上tag。。。总结今天介绍了几个小的GoModule的知识讲了模块版本管理，也讲了一些开发模块时的乱码。我们最好还是遵守上面的，在测试阶段给test分支打上标签，发布的时候一定要合并到trunk里进行正式打标签。项目不要依赖模块的伪版本而上线。发布前检查一下go.mod，及时改过来，就不会像我一样，天天给前辈填坑的大冤家。
