摘要
版本格式：主版本號.次版本號.修訂號，版本號遞增規則如下：
- 主版本號：當你做了不兼容的 API 修改，
- 次版本號：當你做了向下兼容的功能性新增，
- 修訂號：當你做了向下兼容的問題修正，
先行版本號及版本編譯資訊可以加到“主版本號.次版本號.修訂號”的后面，作為延伸，
簡介
在軟體管理的領域里存在著被稱作“依賴地獄”的死亡之谷，系統規模越大，加入的包越多，你就越有可能在未來的某一天發現自己已深陷絕望之中，
在依賴高的系統中發布新版本包可能很快會成為噩夢，如果依賴關系過高，可能面臨版本控制被鎖死的風險（必須對每一個依賴包改版才能完成某次升級），而如果依賴關系過于松散，又將無法避免版本的混亂（假設兼容于未來的多個版本已超出了合理數量），當你專案的進展因為版本依賴被鎖死或版本混亂變得不夠簡便和可靠，就意味著你正處于依賴地獄之中，
作為這個問題的解決方案之一，我提議用一組簡單的規則及條件來約束版本號的配置和增長，這些規則是根據（但不局限于）已經被各種封閉、開放原始碼軟體所廣泛使用的慣例所設計，為了讓這套理論運作，你必須先有定義好的公共 API，這可以透過檔案定義或代碼強制要求來實作，無論如何，這套 API 的清楚明了是十分重要的，一旦你定義了公共 API，你就可以透過修改相應的版本號來向大家說明你的修改，考慮使用這樣的版本號格式：X.Y.Z（主版本號.次版本號.修訂號）修復問題但不影響 API 時，遞增修訂號；API 保持向下兼容的新增及修改時，遞增次版本號；進行不向下兼容的修改時，遞增主版本號，
我稱這套系統為“語意化的版本控制”，在這套約定下，版本號及其更新方式包含了相鄰版本間的底層代碼和修改內容的資訊，
語意化版本控制規范（SemVer）
以下關鍵詞 MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、 RECOMMENDED、MAY、OPTIONAL 依照 RFC 2119 的敘述解讀，
-
使用語意化版本控制的軟體必須（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 檔案中保留此頁鏈接，讓別人也知道這些規則并從中受益，
FAQ
在 0.y.z 初始開發階段，我該如何進行版本控制？
最簡單的做法是以 0.1.0 作為你的初始化開發版本，并在后續的每次發行時遞增次版本號，
如何判斷發布 1.0.0 版本的時機？
當你的軟體被用于正式環境，它應該已經達到了 1.0.0 版，如果你已經有個穩定的 API 被使用者依賴，也會是 1.0.0 版，如果你很擔心向下兼容的問題，也應該算是 1.0.0 版了，
這不會阻礙快速開發和迭代嗎？
主版本號為零的時候就是為了做快速開發，如果你每天都在改變 API，那么你應該仍在主版本號為零的階段（0.y.z），或是正在下個主版本的獨立開發分支中，
對于公共 API，若即使是最小但不向下兼容的改變都需要產生新的主版本號，豈不是很快就達到 42.0.0 版？
這是開發的責任感和前瞻性的問題，不兼容的改變不應該輕易被加入到有許多依賴代碼的軟體中，升級所付出的代價可能是巨大的，要遞增主版本號來發行不兼容的改版，意味著你必須為這些改變所帶來的影響深思熟慮，并且評估所涉及的成本及效益比，
為整個公共 API 寫檔案太費事了！
為供他人使用的軟體撰寫適當的檔案，是你作為一名專業開發者應盡的職責，保持專案高效一個非常重要的部份是掌控軟體的復雜度，如果沒有人知道如何使用你的軟體或不知道哪些函式的呼叫是可靠的，要掌控復雜度會是困難的，長遠來看，使用語意化版本控制以及對于公共 API 有良好規范的堅持，可以讓每個人及每件事都運行順暢，
萬一不小心把一個不兼容的改版當成了次版本號發行了該怎么辦？
一旦發現自己破壞了語意化版本控制的規范，就要修正這個問題，并發行一個新的次版本號來更正這個問題并且恢復向下兼容，即使是這種情況，也不能去修改已發行的版本，可以的話，將有問題的版本號記錄到檔案中，告訴使用者問題所在，讓他們能夠意識到這是有問題的版本，
如果我更新了自己的依賴但沒有改變公共 API 該怎么辦？
由于沒有影響到公共 API，這可以被認定是兼容的，若某個軟體和你的包有共同依賴，則它會有自己的依賴規范，作者也會告知可能的沖突，要判斷改版是屬于修訂等級或是次版等級，是依據你更新的依賴關系是為了修復問題或是加入新功能，對于后者，我經常會預期伴隨著更多的代碼，這顯然會是一個次版本號級別的遞增，
如果我變更了公共 API 但無意中未遵循版本號的改動怎么辦呢？（意即在修訂等級的發布中，誤將重大且不兼容的改變加到代碼之中）
自行做最佳的判斷，如果你有龐大的使用者群在依照公共 API 的意圖而變更行為后會大受影響，那么最好做一次主版本的發布，即使嚴格來說這個修復僅是修訂等級的發布，記住， 語意化的版本控制就是透過版本號的改變來傳達意義，若這些改變對你的使用者是重要的，那就透過版本號來向他們說明，
我該如何處理即將棄用的功能？
棄用現存的功能是軟體開發中的家常便飯，也通常是向前發展所必須的，當你棄用部份公共 API 時，你應該做兩件事：（1）更新你的檔案讓使用者知道這個改變，（2）在適當的時機將棄用的功能透過新的次版本號發布，在新的主版本完全移除棄用功能前，至少要有一個次版本包含這個棄用資訊，這樣使用者才能平順地轉移到新版 API，
語意化版本對于版本的字串長度是否有限制呢？
沒有，請自行做適當的判斷，舉例來說，長到 255 個字元的版本已過度夸張，再者，特定的系統對于字串長度可能會有他們自己的限制，
關于
語意化版本控制的規范是由 Gravatars 創辦者兼 GitHub 共同創辦者 Tom Preston-Werner 所建立，
如果您有任何建議，請到 GitHub 上提出您的問題，
許可證
知識共享 署名 3.0 (CC BY 3.0)
鏈接
語意化版本 2.0.0 | Semantic Versioning (semver.org)
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/296325.html
標籤：訊息安全