工件版本命名

如果你的程序比較大，版本號就變得非常重要。下面的列表展示了版本命名的基本原則：

版本號應該單向遞增，也就是說，變大。

它們應該可以相互比較，這樣就能輕易看出那個版本更新。

為所有工件使用相同的版本號體系。

通常轉換成帶有三四個部分的版本號：

第一部分代表了主要的代碼變更。

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

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

第四部分可以是一個構建號。

看起來挺簡單，為語義化版本號( SemVer)生成標準可是相當費力的。完整的規格可以參考‘http://semver.org。

如果所有的可安裝工件都有一個合適的發布號和一個在源代碼管理系統中相對應的標簽，那是很方便的。

一些工具不是這么工作的。Maven，Java的構建工具，支持快照發布號。一個快照可以被視為一個最后部分很含糊的版本號?？煺沼凶约旱囊恍┤秉c，比如說，你不能立即找到這個產品的源代碼標簽。這讓調試宕掉了的程序變得更困難?！?/p>

產品快照策略還違背了一個基本的測試原則：部署到生產環境的二進制產品應該與測試的產品完全一致。

當以快照方式工作時，直到測試完成之前你使用的一直是快照，之后又發布帶有真實版本號的工件，然后那個工件才被部署上去。而它已經不再是相同的工件了。