之前介绍了如何使用github托管go类库，详见Golang 使用github托管go类库，接着上篇，本篇介绍go类库的版本管理。

Go类库版本规则

go类库版本的规则：主版本号.次版本号.修订号，其中：

• 主版本号：类库进行了不可向下兼容的修改，例如功能重构，这时候主版本号往上追加；
• 次版本号：类库进行了可向下兼容的修改，例如新增功能，这时候次版本号往上追加；
• 修订号：类库进行了可向下兼容的修改（修改的规模更小），例如修复或优化功能，这时候修订好往上追加。

Go类库发版示例

同样以github.com/vsixz/common-go类库为示例。

小版本升级

主版本不升级，次版本或修订版本升级。

v0.x.x版本升级至v1.x.x也是可以直接升级的。

当前版本是v1.0.0，现对该类库进行了功能修改，发布v1.0.1版本：

1、切换至release/1.x分支

git checkout release/v1.x

2、修改类库代码

3、提交代码并发布

git add .
git commit -m "update hello"
git push
git tag v1.0.1
git push --tags 

4、使用demo-go测试，升级版本

升级类库方式：

• 使用go get -u xxx升级至该主版本号下最新版本；
• 使用go get xxx@version升级至指定版本。

$ go get - u github.com/vsixz/common-go
go: downloading github.com/vsixz/common-go v1.0.1
go: found github.com/vsixz/common-go/hello in github.com/vsixz/common-go v1.0.1
go: github.com/vsixz/common-go upgrade => v1.0.1

查看demo-go下的go.mod文件，确实升级到了新版本：

5、运行测试

$ go run main.go
test hello:
Hello, Jay
common-go version: v1.0.1

大版本升级

主版本升级。

值得注意的是，使用go get -u xxx升级类库版本时，无法跨主版本升级，只能升级至当前主版本下最新小版本；

v0.x.x 升级至v1.x.x是个例外，可以直接使用go get -u xxx命令升级。

当前版本是v1.0.1，现对该类库进行了功能重构，发布v2.0.0版本：

1、继续按照最佳实践，创建2.x版本的分支

git checkout -b release/v2.x

2、在类库根目录下创建v2目录，并将当前项目go类库和go.mod全拷贝（或剪切）到v2目录

3、修改module名称至新版

go mod edit -module github.com/vsixz/common-go/v2 v2/go.mod

查看v2/go.mod文件：

修改了module名称后，如果v2目录下的go文件引用本类库的包，需要更新引用v2，否则无法找到引用包。

4、v2类库新增功能

5、提交代码并发布

git add .
git commit -m "refactor hello to v2"
git push -u origin release/v2.x
git tag v2.0.0
git push --tags

6、使用demo-go测试，升级版本

注意，此时无法通过go get -u xxx升级至不同于当前主版本的最新版本，需要使用go get xxx@version升级：

$ go get github.com/vsixz/common-go/[email protected]

查看go.mod文件，已经添加了v2版本依赖包

7、修改测试代码

同时使用v1版本和v2版本的包函数：

8、运行测试

$ go run main.go
test hello:
Hello, Jay
common-go version: v1.0.1
Hello, Jay Chou
common-go version: v2.0.0

使用本地go类库

如果本地的go类库暂未维护到远端，如何引用本地类库的包呢？

在go.mod文件中使用replace引用本地go类库，这个方式有时候更方便于开发。

common-go的module名称为github.com/vsixz/common-go

replace使用go类库相对路径替换module的引用

以下示例将go类库的引用切换为本地引用。

由于是本地引用，版本号只需在主版本号的范围内即可。

结束语

主版本升级会给代码的维护和版本的维护增加难度，并且需要下游用户迁移版本。最好是当存在令人信服的原因时才对类库主版本进行升级，例如为了优化代码大规模重构。