#gomod 版本引入问题

#引入 包版本 v1 v2 v3...

v0.X.X: 对于主版本号(major)是0的情况，隐含你当前的API还处于不稳定的状态，新的小版本可能不向下兼容 v1.X.X: 当前的API处于稳定状态，minor的增加只意味着新的feature的增加，API还是向下兼容的 v2.X.X: major的增加意味着API已经不向下兼容了

go module与众不同鹤立鸡群卓然不群的是，一旦你的major大于等于2, 你的module path必须加上v2后缀(如果tag是v3.X.X,那就是v3后缀，以此类推)。

go.etcd.io/etcd/api/v3 v3.5.4
go.etcd.io/etcd/client/v3 v3.5.4

引用时候 "go.etcd.io/etcd/api/v3/mvccpb" clientv3 "go.etcd.io/etcd/client/v3"

#发布新包

发布新包时，也需遵循规范 module github.com/minio/minio-go/v7

#不规范

如果我们在项目 A 中引用了该 module，使用命令 go mod tidy，go 命令会自动查找 Module m 的最新版本，即 v3.6.0。 由于 Module 为不规范的 Module，为了加以区分，go 命令会在 go.mod 中增加 +incompatible 标识。

require ( github.com/RainbowMango/m v3.6.0+incompatible )

站在 Kubernetes 的角度，此处的困扰在于，如果将来 github.com/blang/semver 发布了新版本 v4.0.0，但不幸的是 Module 名字仍然为 github.com/blang/semver。那么，升级这个 Module 的版本将会变得困难。因为 v3.6.0 到 v4.0.0 跨越了大版本，按照语义化版本规范来解释说明发生了不兼容的改变，即然不兼容，项目维护者有必须对升级持谨慎态度，甚至放弃升级。

站在 github.com/blang/semver 的角度，如果迟迟不能将自身变得 "规范"，那么其他项目有可能放弃本 Module，转而使用其他更规范的 Module 来替代，开源项目如果没有使用者，也就走到了尽头。

---

//indirect 表示间接的依赖.引入一个包 间接引入

---

go mod download 下载依赖包到本地（默认为 GOPATH/pkg/mod 目录） go mod graph 打印模块依赖图 go mod init 初始化当前文件夹，创建 go.mod 文件 go mod tidy 增加缺少的包，删除无用的包 go mod verify 校验依赖 go mod why 解释为什么需要依赖

---

#评论

#评论 1 · 2023-02-21T06:43:17.151000Z

https://colobu.com/2021/06/28/dive-into-go-module-2/

#评论 2 · 2023-02-21T07:01:00.292000Z

https://learnku.com/docs/go-mod/1.17