文章出處

每次打開谷歌瀏覽器的About頁面更新的時候，總是期待著一個新版本的到來，新的東西總是讓人感到Amazing。這樣久了之后心中不免產生一個疑問，什么時候該發布一個新版本了，有什么規律么？平時的小更新總是版本號后面無關僅要的數字的增長，當這個數字增長到何時可以讓主版本號加1？

帶著這個疑惑到StackOverflow造訪了一下，良久無回音。再加上自己寫點小東西時也需要正確地命名版本號來管理發布，看來是有必要補充一下這方面的知識了。

語義化版本號

當我在發布jQuery插件時，發現其官方頁面上提供了一個幫助我們更好地命名軟件版本號的概念"semver"，即Semantic Versioning語義化的版本。看了下其規則覺得很nice。

關于軟件的版本號，向來沒有統一或者嚴格的規定，對于大型軟件產品，其開發團隊內部或許維護了自己的一套規則來界定軟件開發到何時可以發布新版本，何時又只是增加次版本號，也或許在遵循一些現成的大家認可的規范；更多情況是對個人開發者而言，在自己搗騰一些小東西時，這樣的版本號規則就更自由了，完全視軟件作者的水平而良莠不齊。有的作者或許學習過版本相關的知識，知道遵循一些現成的規范，更多的新手比如像我這樣，完全是隨毫無規則地在使用版本號。今天開發完一個功能，那就發布一個版本叫做0.1吧，下午發現個bug并修復之再發個版本0.2吧。如此顯然不好，無規矩不成方圓啊，我們已經飽受各瀏覽器不完全遵循W3C規范而帶來的各種跨瀏覽器前端問題了，血的教訓，歷史告訴我們，不能讓悲劇重演，所以迫切需要一個好的準則來指導大家更好地使用軟件版本號。

語義化版本號的作者正是抱著這樣的希望創造了它。

語義化版本號是由Tom Preston-Werner 發起的一個關于軟件版本號的命名規范，關于這個規范詳細的說明可以在官網查看，也可訪問其GitHub項目頁面，而關于該規范的中文版本，可以訪問我fork的版本，由官網繁體中文轉換而來，并稍加修改以更符合大陸用語。順便提句，該規范的作者是Gravatars創辦者同時是GitHub聯合創始人。你或許不知道gravatar但作為程序員你肯定知道GitHub。

基本規則

顧名思義，語義化的版本就是讓版本號更具語義化，可以傳達出關于軟件本身的一些重要信息而不只是簡單的一串數字。

版本格式：主版本號.次版本號.修訂號，版本號遞增規則如下：

主版本號：當你做了不兼容的API 修改
次版本號：當你做了向下兼容的功能性新增
修訂號：當你做了向下兼容的問題修正

先行版（預覽版）版本號及版本編譯信息可以加到"主版本號.次版本號.修訂號"的后面，作為延伸。

具體規范

具體詳盡的規范可以參見其官網，當然也可以訪問中文版本。這里簡單總結一下。

版本號是以點隔開的形式'X.Y.Z' 且XYZ為正整數，數字前面不加0，也就是說v0.1.0不能寫成v0.01.0
一般軟件開發過程中以0.1.0 版本開始，開發過程中不斷增加新功能，則增加次版本號比如變成0.2.0，然后期間的問題及bug修復體現在修訂號上，比如版本號變成0.1.12。這一階段的版本視為不穩定版本，一般也未對外發布
主版本號表示正式版的形成，也即如果你開發的是供大家使用的軟件或插件，那就標致本軟件公共API的形成，比如新浪微博API v1.0.0發布，大家就可以在自己網站上調用了，這是個正式而穩定的版本。所以這里有個規定，版本一旦發布，不允許對軟件做任何修改。任何改過之后的代碼都應標記新的版本號在下次發布中體現
主版本號的增加可以是次版本號以有修訂號增加到一定數量后的結果，也可以是有不兼容舊版的新功能或API加入的結果，并且主版本增加后次版本號和修訂號歸零
次版本號表示有兼容舊版本的功能或API增加，而修訂號表示bug修復并且這種修復一般是對代碼結果不正確的修復而且一定是兼容舊版本的，如果你修復bug越改越大結果不兼容舊版本了，則需要增加主版本號
其他信息比如預覽版，先行版或者軟件編譯信息可以跟隨在修訂號之后。示例：1.0.0-alpha+001、1.0.0+20130313144700、 1.0.0-beta+exp.sha.5114f85

使用語義化版本號的好處

也即原規范中對為何要使用語義化版本號的描述。在我看來，無非就是在遵循了本規范后，透過版本號，你可以非常清楚地了解到你手頭拿到的軟件版本相比于上一個版本發生了怎樣的變化，所以你在使用的時候可以更注意一下這些變化，以免出現不兼容的情況。

比如如果主版本號升級了，可以知道軟件新增了功能且該功能或者重大問題修復，且都是與舊版本不兼容的。好比大家熱切推崇的文本編輯器Sublimetext2和3，他的很多插件在這兩個版本間無法兼容使用，所以一般要標明插件是使用在Sublimetext2還是3中。同時主版本號的更新也可以表明是次版本號更新到了一定程序，比如新增功能數量達到了一定指標，我們可以認為可以升級一下主版本號了，畢竟一個可以copy as rtf，帶項目文件管理sidebar，更換主題的文本編輯器和Windows自帶文本編輯器在功能上還是有質的區別的。

如果次版本更新了，我們可以知道有小部分新功能添加，或者修訂號更新，有小部分bug被修復，而在獲取這些信息時完全還沒有查看change log。這正是語義化的好處，版本號就告訴你大部分信息了，當然更具體的參見change log吧。

另外個好處就是當大家都在遵循一個規范的時候，無疑掃清了一些認知上的障礙，將事情簡單化，大家也心照不宣地能看懂每個人代碼中的版本號的意思，初學者也很容易掌握這方面的知識。

一些問題

各版本優先級

也即如何判定哪個版本版次更高。下面是來自原規范的解釋，已經夠詳盡就不另外闡述。

判斷優先層級時，必須把版本依序拆分為主版本號、次版本號、修訂號及先行版本號后進行比較（版本編譯信息不在這份比較的列表中）。由左到右依序比較每個標識符號，第一個差異值用來決定優先層級：主版本號、次版本號及修訂號以數值比較，例如1.0.0 < 2.0.0 < 2.1.0 < 2.1.1。當主版本號、次版本號及修訂號都相同時，改以優先層級比較低的先行版本號決定。例如：1.0.0-alpha < 1.0.0。有相同主版本號、次版本號及修訂號的兩個先行版本號，其優先層級必須透過由左到右的每個被句點分隔的標識符號來比較，直到找到一個差異值后決定：只有數字的標識符號以數值高低比較，有字母或連接號時則逐字以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。