go mod

[wangjc0216]

ref:
https://tonybai.com/2022/03/12/dependency-hell-in-go/
https://semver.org/
https://go.dev/blog/module-compatibility

一些零散的点：

1. 钻石依赖问题
2. indirect不会和直接引用写到一起。
3. tag的规则需要遵循x.y.z

go.mod 会指定某一个具体版本，如果版本通过go get被指定，那么对应的依赖版本也会对应的upgrade和downgrade到具体版本。
//indirect则表示的是自己依赖的module所间接依赖的版本。

go mod edit -replace=@Version=

go mod 会在一个major version中选择一个最高版本的，因为go module编写规则中，会认定同一个大版本中，版本是向后兼容的。

以github.com/pierrec/lz4为例，当我执行go get github.com/pierrec/lz4 的时候，会获取v2.6.1+incompatible版本。

伪版本：go list -m -versions github.com/pierrec/lz4 ,可以看到legacy go中的各个版本，和git tag可以对应。

[wangjc0216]

如prometheus，因为项目不满足语义版本控制。
如v2.24.1的所在版本go.mod中不会标明github.com/prometheus/prometheus/v2，所以prometheus在同步打一个v0.24.1，v0可以表明api不兼容。

[wangjc0216]

因为同一个大版本，我们认定是api兼容的，所以对于以下依赖链路，b module对d module的依赖链路，会从v1.2.3升级成1.3.3