如何作废一个已发布的Go module版本，我来告诉你！

1. 一不小心将一个处于broken状态的module发布了出去

人总是会犯错的，作为Go包/module的作者，我们偶尔也会出现这样的低级错误：将一个处于broken状态的module发布了出去。比如：bitbucket.org/bigwhite/m1是我维护的一个module(专为此文创建的公共go module)，它目前已经进化到v1.0.1版本了：

// bitbucket.org/bigwhite/m1/main.go

package m1

import "fmt"

func M1() {
 fmt.Println("This is m1.M1 - v1.0.1")
}

m1这个module有两个消费者：c1和c2，它们依赖的也都是m1的v1.0.1版本：

// c1的go.mod
module github.com/bigwhite/c1

go 1.14

require bitbucket.org/bigwhite/m1 v1.0.1

// c1的main.go
package main

import (
 "fmt"

 "bitbucket.org/bigwhite/m1"
)

func main() {
 fmt.Println("This is c1")
 m1.M1()
}

// c2的go.mod
module github.com/bigwhite/c2

go 1.14

require bitbucket.org/bigwhite/m1 v1.0.1

// c2的main.go

package main

import (
 "fmt"

 "bitbucket.org/bigwhite/m1"
)

func main() {
 fmt.Println("This is c2")
 m1.M1()
}

c1和c2所在的Go开发环境均使用下面的GOPROXY设置：

export GOPROXY=https://goproxy.cn,direct

我们用一幅示意图来描述当前的状态：

以c1为例，构建并运行c1：

// c1的module root目录下
$go build
go: finding module for package bitbucket.org/bigwhite/m1
go: downloading bitbucket.org/bigwhite/m1 v1.0.1
go: found bitbucket.org/bigwhite/m1 in bitbucket.org/bigwhite/m1 v1.0.1

$./c1
This is c1
This is m1.M1 - v1.0.1

接下来，作为m1的作者，我犯了一个低级错误：将更新了的但却无法编译成功的m1打标签为v1.0.2发布了出去：

// bitbucket.org/bigwhite/m1的m1.go
package m1

import "fmt"

func M1() {
 var a int // 编译器错误：a declared but not used
 fmt.Println("This is m1.M1 - v1.0.2")
}

// 在m1的module root目录下
$git commit -m"update m1 to v1.0.2(broken)" .
[master af1dd21] update m1 to v1.0.2(broken)
 1 file changed, 2 insertions(+), 1 deletion(-)
$git tag -m"tag v1.0.2(broken)" v1.0.2
$git push --tag origin master
Enumerating objects: 6, done.
Counting objects: 100% (6/6), done.
Delta compression using up to 8 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 492 bytes | 492.00 KiB/s, done.
Total 4 (delta 1), reused 0 (delta 0)
cTo https://bitbucket.org/bigwhite/m1.git
   911bbc5..af1dd21  master -> master
 * [new tag]         v1.0.2 -> v1.0.2

就这样，我一不小心将一个处于broken状态的module版本m1@v1.0.2发布了出去！此时此刻，m1的v1.0.2版本还仅存在于其源仓库站点上，即bitbucket/bigwhite/m1中，在任何一个GoProxy服务器上还尚无该版本的缓存。

2. 发布处于broken状态的module对“消费者”的影响

依赖m1的两个项目c1和c2此时依赖的仍然是m1@v1.0.1版本，如未显式升级对m1的依赖，c1和c2的构建不会受到处于broken状态的module v1.0.2版本的影响。

并且此时此刻，由于m1@v1.0.2尚未被GoProxy服务器所缓存，在GOPROXY开启的情况下，go list是查不到m1有可升级的版本的：

// 以c2为例：
$go list -m -u all
github.com/bigwhite/c2
bitbucket.org/bigwhite/m1 v1.0.1

但如若绕开GOPROXY，那么go list则可以查找到m1的最新版本为v1.0.2(我们通过设置GONOPROXY来使得go list查询m1的源仓库而不是代理服务器上的缓存)：

$GONOPROXY="bitbucket.org/bigwhite/m1" go list -m -u all
github.com/bigwhite/c2
bitbucket.org/bigwhite/m1 v1.0.1 [v1.0.2]

此时，如若某个m1的消费者在GOPROXY开启的情况下显式更新对m1版本的依赖，以c2如此操作为例：

$ go get bitbucket.org/bigwhite/m1@v1.0.2
go: downloading bitbucket.org/bigwhite/m1 v1.0.2
# bitbucket.org/bigwhite/m1
/root/go/pkg/mod/bitbucket.org/bigwhite/m1@v1.0.2/m1.go:6:6: a declared but not used

c2对m1依赖版本的显式更新，触发了GOPROXY对m1@v1.0.2版本的缓存，上述操作后，当前的状态如下示意图：

这之后，其他m1的消费者，比如c1，便能够在GOPROXY开启的情况下查询到m1存在新版本v1.0.2，即使它是broken的：

// 以c1为例：
$go list -m -u all
github.com/bigwhite/c1
bitbucket.org/bigwhite/m1 v1.0.1 [v1.0.2]

一旦broken的m1版本(v1.0.2)进入到Proxy的缓存，那么其“危害性”便“大肆传播”开了。此时module m1的新消费者都将受到影响！比如这里我们引入一个新的消费者c3(同样设置GOPROXY为goproxy.cn)：

// c3的main.go
package main

import (
 "fmt"

 "bitbucket.org/bigwhite/m1"
)

func main() {
 fmt.Println("This is c3")
 m1.M1()
}

c3的首次构建就会报错：

// c3下：
$go build
go: finding module for package bitbucket.org/bigwhite/m1
go: found bitbucket.org/bigwhite/m1 in bitbucket.org/bigwhite/m1 v1.0.2
# bitbucket.org/bigwhite/m1
/root/go/pkg/mod/bitbucket.org/bigwhite/m1@v1.0.2/m1.go:6:6: a declared but not used

下面是当前问题的最新状态图：

3. 如何作废掉已发布的那个module版本

如果在GOPATH时代，废掉一个之前发的包版本是分分钟的事情，因为那时包消费者依赖的都是latest commit。包作者只要fix掉问题、提交并重新发布即可。

但是在go module时代，作废掉一个已经发布了的go module版本，还真不是一件能轻易做好的事情。这很大程度是源于大量Go module代理服务器的存在。下面我们来看看可能的问题解决方法：

1) 重新发布broken的module版本

要解决上述问题，Go包作者们的一个很直接的解决方法是：重新发布broken的module版本。但这样做真的能生效么？

如果所有m1的消费者都通过m1所在代码托管服务器(bitbucket)获取m1的特定版本，那么这种方法还真能解决掉这个问题。m1的作者仅需删除掉远程的tag: v1.0.2，在本地fix掉问题，然后重新tag v1.0.2并push发布到bitbucket上的仓库中即可。这样，对于已经get到broken v1.0.2的消费者来说，只需清除掉本地的module cache(go clean -modcache)，再重新构建即可；对于m1的新消费者，直接得到的就是重新发布后的v1.0.2版本。

但现实的情况时，Go在1.13版本中就将GOPROXY的默认值设置为https://proxy.golang.org,direct了，国内我们通常使用七牛云的代理：goproxy.cn。因此，一旦一个module版本被发布，当某个消费者通过其配置的goproxy获取该版本时，该版本就会在短时间内被缓存在对应的代理服务器上。后续通过该goproxy服务器获取那个版本的m1时，请求不会再回到m1所在的源代码托管服务器，这样即便m1的源服务器上的v1.0.2版本得到了重新发布，那么散布在各个goproxy服务器上的broken v1.0.2依旧存在，并且被“传播”到各个m1消费者的开发环境中，而重新发布后的v1.0.2版本却得不到“传播”的机会：

因此，从消费者的角度看，m1的v1.0.2版本依旧是一个broken的版本，m1作者的解决措施无效！

很多人问，即便m1的作者删除了v1.0.2这个发布版本，各大goproxy服务器上的broken v1.0.2版本是否也会被删除呢？遗憾的告诉你：不会。

Goproxy服务器当初的一个设计目标就是尽可能的缓存更多包/module。即便某个module的源码仓库都被删除了，这个module的各个版本依旧缓存在goproxy服务器上，这个module的消费者依然可以正常获取该module并顺利构建。因此，goproxy服务器当前的实现都没有主动删掉某个module缓存的特性。

2) 发布module的新patch版本

面对上述问题，Go社区当前的最佳实践就是发布module的新patch版本。以上面m1为例，我们废除掉v1.0.2，在本地修正问题后，直接打v1.0.3标签，并发布push到远程代码服务器上。这样整体状态就变成了下面示意图中样子了：

• 对于依赖m1@v1.0.1版本的c1，在未手工更新依赖版本的情况下，它仍然可以保持成功的构建；
• 对于m1的新消费者，比如c4，它首次构建时使用的就是m1的最新patch版v1.0.3，成功跨过了作废的v1.0.2并成功完成构建；
• 对于之前曾依赖v1.0.2版本的消费者c2来说，此时需要手工介入才能解决问题。我们在c2环境手工升级依赖版本到v1.0.3，这样c2也会得到成功构建。

4. Go 1.16增加retract指示符用于标识作废的module版本

上述的发布module的新patch版本的解决方法其实仍存在两个问题：

• 消费者如何发现m1发布了v1.0.3？
• 消费者如何知晓m1的作者将v1.0.2版本作废掉了？

根据前面的描述，如果尚无消费者手工下载v1.0.3，那么proxy server上不会有v1.0.3版本的缓存，在本地通过go list -u -m all 也查不到v1.0.3的存在，除非是在设置GONOPROXY=bitbucket.org/bigwhite/m1前提下的go list查询。

另外在go 1.15^[3]标识出哪些版本为作废的，不推荐使用的。语法形式如下：

// go.mod
retract v1.0.0           // single version
retract [v1.1.0, v1.2.0] // closed interval

我们还用m1为例，我们将m1的go.mod更新为如下内容：

//m1的go.mod
module bitbucket.org/bigwhite/m1

go 1.16

retract v1.0.2

将其放入v1.0.3标签中并发布！现在m1的消费者c2要查看m1是否有最新版本时，可以查看到以下内容(c2本地环境使用go1.16版本)：

$GONOPROXY=bitbucket.org/bigwhite/m1 go list -m -u all
github.com/bigwhite/c5
bitbucket.org/bigwhite/m1 v1.0.2 (retracted) [v1.0.3]

从go list的输出结果中，我们看到了v1.0.2版本上有了retracted的提示，提示该版本已经被m1的作者作废了，不应该再使用，应升级为v1.0.3。但retracted仅仅是一个提示作用，并不影响go build的结果，c2环境(之前在go.mod中依赖m1的v1.0.2)下的go build不会自动绕过v1.0.2，除非显式更新到v1.0.3。

参考资料