不論是遊戲或者應用軟體開發，一般進行版本的管理都是重要的一步，所以本文摘錄了《語義化版本 2.0.0》的內容，希望大家能認真了解一下版本號的管理方式
版本格式：主版本號.次版本號.修訂號(major.minor.patch)，版本號遞增規則如下：
主版本號(major)：當你做了不相容的 api 修改，
次版本號(minor)：當你做了向下相容的功能性新增，
修訂號(patch)：當你做了向下相容的問題修正。
先行版本號及版本編譯元資料可以加到「主版本號.次版本號.修訂號」的後面，作為延伸。
在軟體管理的領域裡存在著被稱作「依賴地獄」的死亡之谷，系統規模越大，加入的包越多，你就越有可能在未來的某一天發現自己已深陷絕望之中。
在依賴高的系統中發布新版本包可能很快會成為噩夢。如果依賴關係過高，可能面臨版本控制被鎖死的風險（必須對每乙個依賴包改版才能完成某次公升級）。而如果依賴關係過於鬆散，又將無法避免版本的混亂（假設相容於未來的多個版本已超出了合理數量）。當你專案的進展因為版本依賴被鎖死或版本混亂變得不夠簡便和可靠，就意味著你正處於依賴地獄之中。
作為這個問題的解決方案之一，我提議用一組簡單的規則及條件來約束版本號的配置和增長。這些規則是根據（但不侷限於）已經被各種封閉、開放原始碼軟體所廣泛使用的慣例所設計。為了讓這套理論運作，你必須先有定義好的公共 api 。這可以透過檔案定義或**強制要求來實現。無論如何，這套 api 的清楚明了是十分重要的。一旦你定義了公共 api，你就可以透過修改相應的版本號來向大家說明你的修改。考慮使用這樣的版本號格式：x.y.z （主版本號.次版本號.修訂號）修復問題但不影響api 時，遞增修訂號；api 保持向下相容的新增及修改時，遞增次版本號；進行不向下相容的修改時，遞增主版本號。
我稱這套系統為「語義化的版本控制」，在這套約定下，版本號及其更新方式包含了相鄰版本間的底層**和修改內容的資訊。
使用語義化版本控制的軟體必須（must）定義公共 api。該 api 可以在**中被定義或出現於嚴謹的檔案內。無論何種形式都應該力求精確且完整。
標準的版本號必須（must）採用 x.y.z 的格式，其中 x、y 和 z 為非負的整數，且禁止（must not）在數字前方補零。x 是主版本號、y 是次版本號、而 z 為修訂號。每個元素必須（must）以數值來遞增。例如：1.9.1 -> 1.10.0 -> 1.11.0。
標記版本號的軟體發行後，禁止（must not）改變該版本軟體的內容。任何修改都必須（must）以新版本發行。
主版本號為零（0.y.z）的軟體處於開發初始階段，一切都可能隨時被改變。這樣的公共 api 不應該被視為穩定版。
1.0.0 的版本號用於界定公共 api 的形成。這一版本之後所有的版本號更新都基於公共 api 及其修改內容。
修訂號 z（x.y.z | x > 0）必須（must）在只做了向下相容的修正時才遞增。這裡的修正指的是針對不正確結果而進行的內部修改。
次版本號 y（x.y.z | x > 0）必須（must）在有向下相容的新功能出現時遞增。在任何公共 api 的功能被標記為棄用時也必須（must）遞增。也可以（may）在內部程式有大量新功能或改進被加入時遞增，其中可以（may）包括修訂級別的改變。每當次版本號遞增時，修訂號必須（must）歸零。
主版本號 x（x.y.z | x > 0）必須（must）在有任何不相容的修改被加入公共 api 時遞增。其中可以（may）包括次版本號及修訂級別的改變。每當主版本號遞增時，次版本號和修訂號必須（must）歸零。
先行版本號可以（may）被標註在修訂版之後，先加上乙個連線號再加上一連串以句點分隔的識別符號來修飾。識別符號必須（must）由 ascii 字母數字和連線號 [0-9a-za-z-] 組成，且禁止（must not）留白。數字型的識別符號禁止（must not）在前方補零。先行版的優先順序低於相關聯的標準版本。被標上先行版本號則表示這個版本並非穩定而且可能無法滿足預期的相容性需求。範例：1.0.0-alpha、1.0.0-alpha.1、1.0.0-0.3.7、1.0.0-x.7.z.92。
版本編譯元資料可以（may）被標註在修訂版或先行版本號之後，先加上乙個加號再加上一連串以句點分隔的識別符號來修飾。識別符號必須（must）由 ascii 字母數字和連線號 [0-9a-za-z-] 組成，且禁止（must not）留白。當判斷版本的優先層級時，版本編譯元資料可（should）被忽略。因此當兩個版本只有在版本編譯元資料有差別時，屬於相同的優先層級。範例：1.0.0-alpha+001、1.0.0+20130313144700、1.0.0-beta+exp.sha.5114f85。
版本的優先層級指的是不同版本在排序時如何比較。判斷優先層級時，必須（must）把版本依序拆分為主版本號、次版本號、修訂號及先行版本號後進行比較（版本編譯元資料不在這份比較的列表中）。由左到右依序比較每個識別符號，第乙個差異值用來決定優先層級：主版本號、次版本號及修訂號以數值比較，例如：1.0.0 < 2.0.0 < 2.1.0 < 2.1.1。當主版本號、次版本號及修訂號都相同時，改以優先層級比較低的先行版本號決定。例如：1.0.0-alpha < 1.0.0。有相同主版本號、次版本號及修訂號的兩個先行版本號，其優先層級必須（must）透過由左到右的每個被句點分隔的識別符號來比較，直到找到乙個差異值後決定：只有數字的識別符號以數值高低比較，有字母或連線號時則逐字以 ascii 的排序來比較。數字的識別符號比非數字的識別符號優先層級低。若開頭的識別符號都相同時，字段比較多的先行版本號優先層級比較高。範例：1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0。
這並不是乙個新的或者革命性的想法。實際上，你可能已經在做一些近似的事情了。問題在於只是「近似」還不夠。如果沒有某個正式的規範可循，版本號對於依賴的管理並無實質意義。將上述的想法命名並給予清楚的定義，讓你對軟體使用者傳達意向變得容易。一旦這些意向變得清楚，彈性（但又不會太彈性）的依賴規範就能達成。
舉個簡單的例子就可以展示語義化的版本控制如何讓依賴地獄成為過去。假設有個名為「救火車」的函式庫，它需要另乙個名為「梯子」並已經有使用語義化版本控制的包。當救火車建立時，梯子的版本號為 3.1.0。因為救火車使用了一些版本 3.1.0 所新增的功能， 你可以放心地指定依賴於梯子的版本號大等於 3.1.0 但小於 4.0.0。這樣，當梯子版本 3.1.1 和 3.2.0 發布時，你可以將直接它們納入你的包管理系統，因為它們能與原有依賴的軟體相容。
作為一位負責任的開發者，你理當確保每次包公升級的運作與版本號的表述一致。現實世界是複雜的，我們除了提高警覺外能做的不多。你所能做的就是讓語義化的版本控制為你提供乙個健全的方式來發行以及公升級包，而無需推出新的依賴包，節省你的時間及煩惱。
如果你對此認同，希望立即開始使用語義化版本控制，你只需宣告你的函式庫正在使用它並遵循這些規則就可以了。請在你的 readme 檔案中保留此頁鏈結，讓別人也知道這些規則並從中受益。
語義化版本號
本文根據 語義化版本 2.0.0 一文稍作修改。版本格式 主版本號.次版本號.修訂版本號 版本號遞增規則 主版本號 做了不相容的api修改 次版本號 做了向下相容的功能性新增 修訂號 做了向下相容的問題修正。先行版本號及版本編譯元資料可以加到 主版本號.次版本號.修訂號 的後面，作為延伸。用一組簡單...
版本號及使用npm管理專案版本號
版本號 語義化版本 版本號格式 主版本號.次版本號.修訂號 版本號遞增規則 主版本號 做了不相容修改或顛覆式的重寫 次版本號 向下相容的功能性新增 修訂號 向下相容的問題修正 先行版本號及版本編譯資訊可以加到 主版本號.次版本號.修訂號 的後面，作為延伸。版本號只能增加，禁止下降，的修改必須以新版本...
版本號管理規則
版本號配置管理規則 版本號的格式 v 主版本號 副版本號 發布號 版本號的初始值 v1.0.0 管理規則 主版本號 major version 2 設定部門 開發組設定 告知資料結構管理員 3 設定規則 1 涉及到大於10個表的增刪時，主版本號加1 副版本號 minor version 2 設定部門...