为什么要添加版本？
人们有时会问我，为什么我们应该在Go中添加软件包版本。Go没有版本还不够好吗？通常这些人对版本的体验不好在另一种语言中，它们将版本与中断更改关联起来。在这篇文章中，我想谈谈为什么我们需要为Go添加对包版本的支持。稍后的帖子将解释为什么我们不鼓励突破性的改变。
这个去 得到命令有两种因忽略版本而导致的故障模式：它可以使用太旧的代码，也可以使用太新的代码。例如，假设我们想使用包D，那么我们运行去 得到 D类尚未安装任何程序包。这个去 得到命令将下载D的最新副本（不管怎样吉特 克隆降低），已成功生成。为了使我们的讨论更容易，我们称之为D版本1.0并牢记D的依赖性要求（在我们的图表中）。但请记住，虽然我们了解版本的概念和依赖性要求，去 得到没有。
$去拿D
现在假设一个月后，我们想要使用C，这恰好导入了D。我们跑了去 得到 C类.这个去 得到命令下载C的最新副本，正好是C 1.8，而进口D。自去 得到已经下载了D的副本，它正在使用该副本而不是承担新下载的费用。不幸的是，C的构建失败了：C正在使用D 1.4中引入的D的新功能，和去 得到正在重用D 1.0。代码太旧。
$go获取C
接下来我们试着跑步去 得到 -u个，它下载最新的所有相关代码的副本，包括已经下载的代码。
$go获取-u C
不幸的是，D 1.6在一小时前发布包含破坏C的错误。现在代码太新了。从上面看这出戏，我们知道去 得到需要做的事情：使用D≥1.4但不使用D 1.6，因此可能使用D 1.4或D 1.5。很难说去 得到今天，因为它不理解包版本的概念。
回到帖子中的原始问题，为什么要向Go添加版本？
因为同意版本控制系统——版本标识符的语法，以及如何对其进行排序和解释的规则这是一种我们与工具以及彼此之间进行更精确沟通的方式，我们指的是哪一份包裹。正如我们刚才看到的，版本控制对于正确的构建至关重要，但它也支持其他有趣的工具。
例如，显而易见的下一步是能够列出给定的构建以及其中是否有可用的更新。概括地说，有一个工具检查构建列表，可能包括在给定公司，并组装相同的列表。这样的版本列表可以用于合规性检查，对bug数据库的查询等等。在构建的二进制文件中嵌入版本列表甚至可以允许程序代表自己进行这些检查当它运行时。当然，这些都已经存在于其他系统中：我并不是说这些想法是新颖的。关键是要就版本控制系统达成协议启用所有这些工具，甚至可以在语言工具链之外构建。
我们还可以从查询工具转移到您的代码，到开发工具，这些工具会为您更新它。例如，下一步显而易见的是更新工具包对其最新版本的依赖性包测试时自动执行而它的依赖关系仍在继续。能够描述版本也可能使应用代码清理的工具。例如，拥有版本可以让我们编写指令“当使用D版本≥1.4时，更换常见的客户端代码习惯用法x.Foo（1）。酒吧（2）具有x.食品（）”那种工具去 修理无法执行。
我们工作的目标是向核心Go工具链添加版本，一般来说，将它们添加到共享工作词汇表中Go开发人员和我们的工具都是为了建立一个基础这有助于解决核心问题，如建立工作计划而且还支持像这样有趣的外部工具，当然还有其他我们还没有想到的。
如果我们正在为其他工具奠定基础，我们应该瞄准使基础尽可能多功能、坚固和坚固，以尽可能少的阻碍启用尽可能多的其他工具尽可能使用这些工具。我们不仅仅是在编写一个工具。我们正在定义所有这些工具协同工作的方式。这个基础是广义上的API必须针对这些程序编写。与任何API一样，我们希望选择的设计强大到足以支持多种用途但同时简单、可靠、一致、连贯，并且可以预测。未来的帖子将探讨vgo的设计决策针对这些属性。