工件版本命名

如果你的程序比较大，版本号就变得非常重要。下面的列表展示了版本命名的基本原则：

版本号应该单向递增，也就是说，变大。

它们应该可以相互比较，这样就能轻易看出那个版本更新。

为所有工件使用相同的版本号体系。

通常转换成带有三四个部分的版本号：

第一部分代表了主要的代码变更。

第二部分是次要变更，API向后兼容。

第三部分表示修复了缺陷。

第四部分可以是一个构建号。

看起来挺简单，为语义化版本号( SemVer)生成标准可是相当费力的。完整的规格可以参考‘http://semver.org。

如果所有的可安装工件都有一个合适的发布号和一个在源代码管理系统中相对应的标签，那是很方便的。

一些工具不是这么工作的。Maven，Java的构建工具，支持快照发布号。一个快照可以被视为一个最后部分很含糊的版本号。快照有自己的一些缺点，比如说，你不能立即找到这个产品的源代码标签。这让调试宕掉了的程序变得更困难。’

产品快照策略还违背了一个基本的测试原则：部署到生产环境的二进制产品应该与测试的产品完全一致。

当以快照方式工作时，直到测试完成之前你使用的一直是快照，之后又发布带有真实版本号的工件，然后那个工件才被部署上去。而它已经不再是相同的工件了。