提到語義化版本，你可能不是很熟悉，但是這幾乎是每個開發者都接觸的非常多的一種版本管理方式，當你所使用的軟體的版本以比如gitlab 12.10.5的方式進行版本的介紹的時候，這就是一種典型的語義化版本方式。這篇文章以中文版的語義化版本說明為基礎進行使用解釋。
相較於定義，建議先記住這樣乙個示例更容易理解：
版本格式：主版本號.次版本號.修訂號版本示例：12.10.5
官方說明：主版本號：當你做了不相容的 api 修改，
次版本號：當你做了向下相容的功能性新增，
修訂號：當你做了向下相容的問題修正。
先行版本號及版本編譯資訊可以加到「主版本號.次版本號.修訂號」的後面，作為延伸。
解讀：主版本號一般對應於大版本，主要在於不向下相容的情況出現。次版本號為小版本號，對應於一般向下相容的的特性開發，而修訂號一般對應於bug修正。編譯資訊等可以追加至修訂號後，作為延伸擴充套件。
建議1: 初始開發階段（0.y.z）的版本控制方式，建議以0.1.0作為初始化開發版本，後續每次髮型遞增版本號。
建議2: 當軟體被用於正式環境，已經有了穩定的api（功能性對外暴露的介面或者說明），就可以作為1.0.0版本。
建議3: 語義化版本並不會阻礙快速迭代開發，它就是為了更好地管理快速迭代開發過程中的版本管理的。對於迭代開發堅持使用語義化版本進行版本控制。
建議4: 即使很小的不向下相容的更新都應該造成主版本號的更新，在設計階段需要有一定的前瞻性，不然可能就會出現235.2.3這樣的版本號，主版本號發行不相容的版本，所付出的代價可能是很大的，尤其作為基礎元件被引用時，此類發版前往往需要進行成本和效益的綜合評估。
建議5: 發錯版本號，比如將不相容的問題當作小版本進行了發布，嚴格來說需要進行修正，並發行乙個新的此版本號來更正並恢復向下相容，但是也不能去修改已發行的版本，盡可能的將問題的資訊記錄到release note中，使得使用者對此問題有所了解。
建議6: 對於即將棄用的功能，首先應該更新你的release note和說明文件讓使用者知道這個改變，然後在適當的時機將棄用的功能透過新的次版本號發布。在新的主版本完全移除棄用功能前，至少要有乙個次版本包含這個棄用資訊，這樣使用者才能平順地轉移到新版 api。
建議7: 語義化版本雖然對於版本的字串長度沒有限制，但是過長顯然是不太合適的，比如超過255的話就已經顯得很誇張，建議版本號中不要包含過多內容，即使包含，可以通過資訊壓縮來實現。使用語義化版本控制的軟體必須（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。
# 參考文件
語義化版本 版本號管理
不論是遊戲或者應用軟體開發，一般進行版本的管理都是重要的一步，所以本文摘錄了 語義化版本 2.0.0 的內容，希望大家能認真了解一下版本號的管理方式 版本格式 主版本號.次版本號.修訂號 major.minor.patch 版本號遞增規則如下 主版本號 major 當你做了不相容的 api 修改，次...
語義化版本號
本文根據 語義化版本 2.0.0 一文稍作修改。版本格式 主版本號.次版本號.修訂版本號 版本號遞增規則 主版本號 做了不相容的api修改 次版本號 做了向下相容的功能性新增 修訂號 做了向下相容的問題修正。先行版本號及版本編譯元資料可以加到 主版本號.次版本號.修訂號 的後面，作為延伸。用一組簡單...
長知識 語義化版本控制
版本格式 主版本號.次版本號.修訂號，版本號遞增規則如下 主版本號 當你做了不相容的 api 修改，次版本號 當你做了向下相容的功能性新增，修訂號 當你做了向下相容的問題修正。先行版本號及版本編譯元資料可以加到 主版本號.次版本號.修訂號 的後面，作為延伸。在軟體管理的領域裡存在著被稱作 依賴地獄 ...