前言 成功的项目随着逐步成熟以及新功能的加入，过去的特性和设计方案可能不能满足需求。开发者可能想整合一下他们所学的知识比如移除废弃函数、重命名参数或者分割复杂的包为多个可维护模块。这些变更都需要下游用户付出努力来迁移他们的代码来适配新的API，所以他们不会没有认真权衡过收益和成本而做出变更的。 对于一些还在实验中的项目，比如主版本为v0的项目，用户会预期到偶尔的重大变更。对于已经发布为稳定版本的项目，比如主版本为v1或者更高版本的项目，重大的变更需要在一个大版本上进行。这篇文章主要介绍了大版本策略、如果创建并发布一个新的大版本以及如何维护一个module的多个主版本。 * 主版本与module path * 主版本策略 * 发布v2及后续版本 主版本与module path modules模式规范了一个重要的原则，导入兼容性原则： 如果一个老版本的包和一个新版本的包使用相同的导入path，那么新版本的包必须向后兼容老版本的包。 一个新的大版本的包不会向后兼容之前的版本。这就意味着一个新的大版本module必须有一个不同于历史版本的module path。从v2版本开始，

前言 这篇文章将讨论如何编写并发布可被其他module依赖引用的一个module。 注意：这篇主要涉及开发配置直至v1版本，如果你对v2版本迭代感兴趣，可以参考v2版本与版本迭代 [https://www.nitrohsu.com/v2-go-modules]。 本文默认使用Git作为例子， 但是Mercurial、Bazaar等其他版本管理工具也是支持的。 * 项目配置 * 版本与module * v0-初始版本、非稳定版本 * v1-第一个稳定版本 项目配置 本文需要你有一个已经存在的项目作为例子，所以我们以认识Go modules [https://www.nitrohsu.com/golang-modules.html] 文章结尾的文件为例子： > $ cat go.mod module example.com/hello ​ go 1.12​ require rsc.io/quote/v3 v3.1.0 ​ $ cat go.

前言 本文内容结合自己的理解，对Golang官方博客针对Golang新版本modules包管理系统的文章翻译。 使用Go modules Go从1.11和1.12已经初步支持modules，新版Go包依赖管理系统通过显性的版本依赖使得更加易于维护。这篇文章主要介绍了在开始使用Golang modules时的一些基本操作。 一个module是许多Go Pakcage的集合，在它的根目录有一个go.mod文件。go.mod文件中定义这个module的module路径，也定义了需要导入的module路径、外部依赖，这些都是modules成功构建所必须的。每一个外部依赖都有一个module路径和版本号组成。 从Go 1.11开始，如果当前目录或者它的父级目录中有go.mod文件并且此目录不在$GOPATH/src 下面，go命令就会开启对modules的支持（如果在$GOPATH/src目录下，为了保持兼容即便存在go.mod文件go命令还会使用原有的GOPATH模式）。从Go 1.13开始module模式就会默认启用了。 下面就开始介绍在使用module模式开发Go代码过程中的几个步

前言 在golang工程中可以使用多种依赖管理策略，像dep、glide这种Vendoring工具非常的流行，但是它们又各自为政并不能很好的兼容。很多项目把工程文件放在GOPATH目录下存储为一个Git仓库，其他人通过 go get命令依赖存放在GOPATH中最新版本的代码。 Go modules系统在Go1.11时发布，它通过go命令提供了一个官方的依赖管理解决方案。这篇文章主要讲述了迁移原有工程到modules的一些工具和技术。 注意：如果你的工程已经标记为v2.0.0或者更高版本，在增加go.mod文件时需要更新工程中的module path。我们将会在后面的文章中解释如何做才能在v2或者更高版本时不让你的用户糟心。 * 原工程中使用了依赖管理工具 * 使用一个依赖管理器 * 不使用依赖管理器 * 在modules模式下的测试用例 * 发布一个版本 * 导入和规范module path [import_module] 原工程中使用了依赖管理工具 为了转换一个使用依赖管理工具的工程，需要执行以下命令： > $ git clone https://github.