論「版本號」的正確使用方式

　　版本號，說白了就是我們爲項目的每個不同版本起的標識號，其被廣泛運用於開發的各種場景：NPM（Node Package Manager） 的版本定義、對 NPM 包的特定版本的依賴指定、Git 的 daily 版本號分支等等。面對如此多的場景，版本號的命名卻存在很大問題。例如：

• 開始寫一個新項目 / 模塊時，不管三七二十一，都從0.0.1起版本，直到項目不再維護時，版本還停留在0.0.48，前兩位永遠都是0。
• API 變化巨大，而版本號雷打不動一步一個腳印。一個二方包從0.0.8升級到0.0.9就引起了整個項目的崩潰。
• 依賴二方 / 三方包時，不知道該依賴哪個版本，有時隨便指定了一個，有時則直接依賴了*。

版本號的命名

　　根據國際主流的慣例，我們使用「語義化版本（Semantic Versioning）」的命名方式，有時簡稱 SemVer。語義化版本號（以下簡稱「版本號」）的格式是：<major>.<minor>.<patch>。即使用三位非負整數，以點號.連接。

• 如：1.4.15、6.2.0。

每一位版本號的含義

• <major>即主版本號，俗稱大版本升級。改動到主版本號時，標誌着 API 發生了巨大變化，包括但不限於新增特性、修改機制、刪除功能， 一般不兼容上一個主版本號。
• <minor>即次版本號，俗稱小版本升級。當我們進行常規的新增或修改功能時，改動次版本號，但是必須是向前兼容的。這也意味着我們不能直接刪除某個功能。如若必要，我們可以在修改日誌中標記某項功能爲「即將刪除（Deprecated）」，然後在下一個大版本中將其徹底刪除。
• <patch>即修訂號，俗稱 bug 修復。顧名思義，如果僅僅爲了修復或調整一些小問題，我們就只改動修訂號。

所以，當我們明確了每一位的含義和作用後，就不會陷入「每次只改最末位」的尷尬中了。那如何判斷一個修改應該是改動修訂號還是次版本號呢？視情況而定。比如對於「修改了 app 圖標」這件事來說，如果只是調整了圖標的間距位置，那麼可以認作問題修復；如果把整個圖標換了，配上了不同的標語，那麼這應該是一次功能改動。

注意事項

• 版本號前不要加v。
• 不要在數字前補0。錯誤示例：01.12.03。
• 每一位版本號按照+1的速度遞增，不要在版本號之間跳躍。
• 主版本號停留在0的版本號，即0.x.x應當視作還在內部開發階段的代碼。如果代碼有公共 API，此時不宜對外公開。
• 1.0.0的版本號用於界定公共 API 的形成。
• 當次版本號遞增時，修訂號歸零；當主版本號遞增時，次版本號、修訂號歸零。
• 進行新的開發時，版本號從0.1.0開始。
• 如果不小心把一個不兼容的改版當成了次版本號發行，應當發行一個新的次版本號來更正這個問題並且恢復向下兼容。注意不能去修改已發行的版本。

一個典型的版本號發展示例

• 0.1.0
• 0.1.1
• 0.1.2
• 0.2.0
• 1.0.0
• 1.1.0
• 1.1.1
• ……

快速修改版本號

如果一個包發佈在 NPM / TNPM 中，可以快速修改其版本號。會自動觸發一個 Git 提交。

# 遞增一個修訂號
npm version patch

# 遞增一個次版本號
npm version minor

# 遞增一個主版本號
npm version major

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8

---

預發版本號

　　在常規的版本號命名之上還有一個特殊類別，叫做預發版本號（Prerelease Version）。它表示當前版本是一個不穩定的版本，使用它時需要注意風險。

　　預發版本號的格式是<major>.<minor>.<patch>-<tag>，即前半部分和常規版本號相同，然後跟上連接符-，後面再跟上字母數字點號連接符（[0-9A-Za-z-.]）。

　　一個典型的預發版本號形如1.0.0-beta.1。建議使用這種<major>.<minor>.<patch>-<stage>.<num>的形式。其中<stage>一般選用：alpha、beta、rc。

　　預發版本號是常規版本號的附屬，因此在版本的大小比較上，仍然先比較常規版本號部分；對於預發標記部分的比較，則是根據 ASCII 字母表中的順序來進行。

一個典型的預發版本號發展示例

• 0.9.0
• 1.0.0-alpha.1
• 1.0.0-alpha.2
• 1.0.0-beta.1
• 1.0.0-rc.1
• 1.0.0
• 1.0.1
• ……

依賴的版本號標記法

　　我們廣泛使用的 NPM 本身也遵從 SemVer 版本號命名，除了包版本本身的定義之外，最重要的是對三方包依賴的版本號的定義，不當的寫法將導致一系列潛在的問題。

指定可用的版本號範圍

　　在 NPM 包的 deps 系列字段中，經常出現形如~1.0.4、^2.1.1 這樣的標記法，這種標記法標記的是「版本號範圍（Version Range）」，它表示依賴的三方包其版本號只要落在定義版本號範圍內，即算合法。另外，當運行 npm update 時，依賴的包將升級到版本號範圍支持的最高版本。

　　版本號範圍的標記符號有很多種，諸如比較符號>=、<等；連接符-；通配符x、*；模糊符^、~。具體的用法可參考「NPM 官方文檔」，這裏僅給出常用的標記方式。

含義	最簡	通配符	模糊符	版本號範圍
僅跟進修復版本	1.0	1.0.x	~1.0.4	>=1.0.4 <1.1.0
跟進每個小版本更新	1	1.x、1.x.x	^1.0.4	>=1.0.4 <2.0.0
始終升級到最新版	*	*	*	>=0.0.0

　　我們建議在寫法上採用 「使用通配符的寫法」，並且一般情況下 「跟進每個小版本更新」，但不「始終升級到最新版」，即書寫爲1.x。由於<major>位版本是不向下兼容的，所以在大版本的控制上，仍然採用人爲干預以保證安全。

不同的 deps 字段

　　NPM 包中的依賴有幾種形式的字段：dependencies、devDependencies、peerDependencies。以下簡要介紹下各字段的不同含義，以及使用場景。

字段	含義	依賴被安裝的時機	使用場景
dependencies	運行時依賴，包的調用者需要使用到的依賴	執行 npm install 後會把當前包的dependencies 字段中的所有依賴項安裝到./node_modules目錄。執行 npm install xxx 後會把 xxx 安裝到./node_modules下，同時會安裝 xxx 的 dependencies 字段依賴項到./node_modules/xxx/node_modules目錄。 執行 npm install xxx –save 後會額外把 xxx 作爲依賴存到當前包的 dependencies 字段中。	所有程序運行需要用到的依賴代碼，如 lodash 等。
devDependencies	開發時依賴，包的開發維護者需要使用到的依賴	執行 npm install 後也會把當前包的devDependencies 字段中的所有依賴項安裝到./node_modules目錄。執行 npm install xxx 後會把 xxx 安裝到./node_modules下，但不會安裝 xxx 的 devDependencies 字段依賴項。執行 npm install xxx –save-dev 後會額外把 xxx 作爲開發時依賴存到當前包的 devDependencies 字段中。	一般是一些開發調試的輔助工具，如測試工具 mocha、構建工具 gulp 等。
peerDependencies	略	略	僅在特定場景下有用，默認不使用此字段。

---

轉載聲明：本文轉自「匯智網」，論版本號的正確打開方式，略有修改。

轉自：http://blog.csdn.net/qq_35246620/article/details/78443169 侵刪