本文根據《語義化版本 2.0.0》一文稍作修改。
版本格式
主版本號.次版本號.修訂版本號
版本號遞增規則
主版本號：做了不相容的api修改；
次版本號：做了向下相容的功能性新增；
修訂號：做了向下相容的問題修正。
先行版本號及版本編譯元資料可以加到「主版本號.次版本號.修訂號」的後面，作為延伸。用一組簡單的規則及條件來約束版本號的配置和增長。需要定義好公共的api，可以通過檔案定義或**強制要求來實現。這樣可以修改相應的版本號來說明修改。
採用以下格式：
x.y.z（主版本號.次版本號.修訂號）
修復問題但不影響api時，遞增修訂號；api保持向下相容的新增及修改時，遞增次版本號；進行不向下相容的修改時，遞增主版本號。
rfc（request for comments，意見徵求稿），涵蓋了網際網路的各種標準。rfc 2119講的是在rfc中用於指示需求級別的關鍵字,包括must"，「must not」，「required」，「shall」，「shall not」，「should」，「should not」， 「recommended」， 「may」 以及 「optional」。
使用語義化版本控制的軟體必須（must）定義公共api。該api可以在**中被定義或出現於嚴謹的檔案內。無論何種形式都應該力求精確且完整。
標準的版本號必須（must）採用x.y.z的格式，其中x、y和z為非負的整數，且禁止（must not）在數字前方補零。x是主版本號、y是次版本號、z是修訂號。每個元素必須（must）以數值來遞增。例如：1.9.1–>1.10.1–>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.37、1.0.0-x.7.z.92。
版本編譯元資料可以（may）被標註在修訂版或先行版本號之後，先加上乙個加號再加上一連串以句點分隔的識別符號來修飾。識別符號必須（must）由ascii字母數字和連線號[0-9a-za-z]組成，且禁止（must not）留白。當判斷版本的優先層級時，版本編譯元資料可（sholud）被忽略。因此當兩個版本只有在版本編譯元資料有差別時，屬於相同的優先層級。例如：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。當主版本號、次版本號及修訂號的兩個先行版本號，其優先層級必須（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 的內容，希望大家能認真了解一下版本號的管理方式 版本格式 主版本號.次版本號.修訂號 major.minor.patch 版本號遞增規則如下 主版本號 major 當你做了不相容的 api 修改，次...
C 使用轉換語義版本號
本文告訴大家如何轉換語義版本號，那麼什麼是語義版本號，語義版本號 semantic version 就是版本號帶 alpha 等的版本號 在以前的版本號都是這樣1.2.1的格式，這個格式可以使用微軟的 version 類轉換 var str 1.2.1 var version version.par...
C 使用轉換語義版本號
本文告訴大家如何轉換語義版本號，那麼什麼是語義版本號，語義版本號 semantic version 就是版本號帶 alpha 等的版本號 在以前的版本號都是這樣1.2.1的格式，這個格式可以使用微軟的 version 類轉換 var str 1.2.1 var version version.par...