版本选择机制-地鼠文档

在前面的章节中，我们使用过go get <pkg>来获取某个依赖，如果没有特别指定依赖的版本号，go get会自动选择一个最优版本，并且如果本地有go.mod文件的话，还会自动更新go.mod文件。

事实上除了go get，go build和go mod tidy也会自动帮我们选择依赖的版本。这些命令选择依赖版本时都遵循一些规则，本节我们就开始介绍Go module涉及到的版本选择机制。

依赖包版本约定

关于如何管理依赖包的版本，Go语言提供了一个规范，并且Go语言的演进过程中也一直遵循这个规范。

这个非强制性的规范主要围绕包的兼容性展开。对于如何处理依赖包的兼容性，根据是否支持Go module分别有不同的建议。

Go module 之前版本兼容性

在Go v1.11（开始引入Go module的版本）之前，Go 语言建议依赖包需要保持向后兼容，这包括可导出的函数、变量、类型、常量等不可以随便删除。以函数为例，如果需要修改函数的入参，可以增加新的函数而不是直接修改原有的函数。

如果确实需要做一些打破兼容性的修改，建议创建新的包。

比如仓库github.com/RainbowMango/xxx中包含一个package A，此时该仓库只有一个package：

github.com/RainbowMango/xxx/A

那么其他项目引用该依赖时的import 路径为：

import "github.com/RainbowMango/xxx/A"

如果该依赖包需要引入一个不兼容的特性，可以在该仓库中增加一个新的package A1，此时该仓库包含两个包：

github.com/RainbowMango/xxx/A
github.com/RainbowMango/xxx/A1

那么其他项目在升级依赖包版本后不需要修改原有的代码可以继续使用package A，如果需要使用新的package A1，只需要将import 路径修改为import "github.com/RainbowMango/xxx/A1"并做相应的适配即可。

Go module 之后版本兼容性

从Go v1.11版本开始，随着Go module特性的引入，依赖包的兼容性要求有了进一步的延伸，Go module开始关心依赖包版本管理系统（如Git）中的版本号。尽管如此，兼容性要求的核心内容没有改变：

如果新package 和旧的package拥有相同的import 路径，那么新package必须兼容旧的package;
如果新的package不能兼容旧的package，那么新的package需要更换import路径；

在前面的介绍中，我们知道Go module 的go.mod中记录的module名字决定了import路径。例如，要引用module module github.com/renhongcai/indirect中的内容时，其import路径需要为import github.com/renhongcai/indirect。

在Go module时代，module版本号要遵循语义化版本规范，即版本号格式为v<major>.<minor>.<patch>，如v1.2.3。当有不兼容的改变时，需要增加major版本号，如v2.1.0。

Go module规定，如果major版本号大于1，则major版本号需要显式地标记在module名字中，如module github.com/my/mod/v2。这样做的好处是Go module 会把module github.com/my/mod/v2 和 module github.com/my/mod视做两个module，他们甚至可以被同时引用。

另外，如果module的版本为v0.x.x或v1.x.x则都不需要在module名字中体现版本号。