这是我参与「第五届青训营 」伴学笔记创作活动的第2天

Version版本号的意义

语义化版本

${MAJOR}.${MINOR}.$${PATCH}：V 1.3.0

• MAJOR：大版本号，不同的major版本可以不兼容，代码隔离
• MINOR：小版本号，新增函数或者功能，需要兼容
• PATCH：代码化的修复

基于commit伪版本

vX.0.0-yyyymmddhhmmss-abcdefgh1234

版本号 - 时间戳 - 12位的hash码前缀

依赖配置

如何记录每次版本的每次提交

• 模块目录：依赖管理基本单元
• 原生库的版本号
• 单元依赖
• • 模块路径 + 版本号

1. indirect：间接依赖

2. A->B->C：A->C间接依赖

3. 主版本2以上的模块 需要在模块路径后边增加/vN后缀

   example/lib5/v3 v3.2.0

4. incompatitble：对于没有go mod文件，并且主版本2以上的依赖，会加上incompatitble标识

依赖图

B：go会选择最低的兼容版本

依赖分发

直接从第三方代码仓库去clone依赖会出现一些问题： 第三方仓库应该仅仅用作代码管理，通过go Proxy 解决

1. 会缓存原站中的每个版本的内容
2. 实现稳定，可靠的依赖分发 通过GOPROXY环境变量来设置代理

go工具

go get

go mod

早期GOPATH

• 第三方的包都是放在gopath里边进行管理的
• 通过环境变量设置系统级的Go语言类库目录
• GOPATH的问题？
  • 不同项目可能依赖不同版本
  • 代码被clone以后需要设置GOPATH才能编译

vendor

• 自1.6版本，支持vendor目录，在每个Go语言项目中，创建一个名叫vendor 的目录，并将依赖拷贝至该目录。
• Go 语言项目会自动将vendor 目录作为自身的项目依赖路径
• 优点
  • 每个项目的vendor目录是独立的，可以灵活的选择版本
  • Vendor 目录与源代码一起checkin 到github，其他人checkout 以后可直接编译
  • 无需在编译期间下载依赖包，所有依赖都已经与源代码保存在一起

go mod

• 通过声明式配置，实现vendor 管理的自动化
• 在早期，Go语言无自带依赖管理工具，社区方案鱼龙混杂比较出名的包括Godeps, Glide，Go语言随后发布了自带的依赖管理工具Gopkg，很快用新的工具gomod替换掉了gopkg
• 切换mod开启模式：export GO111MODULE=on/off/auto
• Go mod相比之前的工具更灵活易用，以基本统一了Go 语言依赖管理
• 问题：用依赖管理工具的目的？
  • 版本管理
  • 防篡改

go mod使用：

1. 创建项目
2. 初始化Go模块：go mod init
3. 下载依赖包
4. go mod download（下载的依赖包在$GOPATH/pkg，如果没有设置GOPATH，则下载在项目根目录/pkg） 在源代码中使用某个依赖包，如github.com/emicklei/go-restful
5. 添加缺少的依赖并为依赖包瘦身
6. go mod tidy
7. 把Go依赖模块添加到vendor目录
8. go mod vendor
9. 配置细节会被保存在项目根目录的go.mod中可在require或者replacement中指定版本