語義化版本控制（Semantic Versioning）

一、格式

版本號為 MAJOR.MINOR.PATCH，點號是分隔符：

• MAJOR。進行了不兼容的 API 改動

• MINOR。添加了向後兼容的新特性

• PATCH。進行了向後兼容的 bug 修復

所以，一般不更新依賴 package 的主版本（MAJOR）

二、範圍

用於依賴管理，聲明目標 package 版本範圍，為自動更新依賴提供支持

• * | x | X

  接受任何可用版本，默認取最新的。不要用，主版本更新可能會引發 bug

• MAJOR | MAJOR.MINOR

  分別表示 <m+1 和 <m.n+1，用 \* 或者 x（m.x.x | m.n.*）也可以表達相同的範圍

• -，<，<=，> 和 >=

  m.n.p - M.N.P 表示 >=m.n.p 且 <=M.N.P

• ~

  ~m.n.p 表示 >=m.n.p 且 <m.n+1.0

• ^

  ^m.n.p 表示 >=m.n.p 且 <m+1.0.0

• 0.n.p

  主版本號為 0 表示處於初步開發階段，所有東西隨時都可能變動，MINOR 和 PATCH 都沒有意義。此時*^ 前綴無效*，^0.n.p 等價於 0.n.p。~ 前綴仍然有效

三、注意事項

語義化版本控制只用於開發環境。也就是說，如果擔心語義化版本控制會把 bug 引入生產環境，就說明用錯了。

只在開發環境中使用的具體方法如下：

• 用 package.json 的 "bundledDependencies" 打包依賴

• 用 npm shrinkwrap 指令創建特定時刻的依賴層級結構快照

• 把依賴隨應用一起加入版本控制（比如 git）

四、關於測試版

Alpha、Beta、Gamma 與 α、β、λ 諧音，是希臘字母前三個字母，用來表示軟件開發過程中測試的三個階段：

• Alpha

  內測版，內部交流或者專業測試人員測試用

• Beta

  公測版，專業愛好者大規模測試用，存在一些缺陷，該版本也不適合一般用戶安裝

• Gamma

  比較成熟的測試版，與即將發行的正式版相差無幾

• RC

  是 Release Candidate 的縮寫，意思是發布倒計時，候選版本，處於 Gamma 階段，該版本已經完成全部功能並清除大部分的 BUG。到了這個階段只會除 BUG，不會對軟件做任何大的更改。從 Alpha 到 Beta 再到 Gamma 是改進的先後關係，但 RC1、RC2 往往是取捨關係

• Stable

  穩定版。在開源軟件中，都有 stable 版，這個就是開源軟件的穩定發行版（對 Node 來說不是這樣的，詳細請查看 [Windows/Linux 下 Node 更新](/articles/windowslinux 下 node 更新/)）

對於範圍 >1.2.3-alpha.3，版本 1.2.3-alpha.7 符合條件，而 3.4.5-alpha.9 卻不滿足條件。雖然 3.4.5-alpha.9 實際上大於 1.2.3-alpha.3，但是根據 SemVer 的排序規則，這個版本範圍只是接受 1.2.3 的測試版，而不接受其他版本的測試版。當然 3.4.5 滿足條件，因為它不是測試版，並且大於 1.2.3-alpha.7

這麼做是有兩個目的，首先測試版會經常更新並且可能包含不適合公開的重大改動，因此被排除在範圍之外。再者，雖然用戶明確此次使用有風險的測試版本，然而下一版本的測試版被包含進來仍然是不合適的

五、總結

不要用固定版本號的依賴，因為補丁（PATCH）更新可能會修復現有 bug，一般有三種：

• 謹慎控制依賴版本：使用 ^ 前綴，表示只更新補丁版本，不跟主版本和小版本。適用於更新不頻繁的趨於穩定的項目（比如 should）

• 稍微寬鬆一點：使用 ~ 前綴，表示不跟主版本，只更新小版本和補丁。適用於長期頻繁更新的大項目（比如 express）

• 最寬鬆的：使用 * 前綴，取最新版本。適用於個人小項目，實驗性的項目（比如 myproj）

參考資料

• Semver: A Primer

• 語義化版本（SemVer）的範圍