語義化的軟體版本号規則 你是否真的了解軟體的版本号

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

語義化版本号

當我在釋出jQuery插件時，發現其

官方頁面

上提供了一個幫助我們更好地命名軟體版本号的概念"

semver

"，即Semantic Versioning語義化的版本。看了下其規則覺得很nice。

關于軟體的版本号，向來沒有統一或者嚴格的規定，對于大型軟體産品，其開發團隊内部或許維護了自己的一套規則來界定軟體開發到何時可以釋出新版本，何時又隻是增加次版本号，也或許在遵循一些現成的大家認可的規範；更多情況是對個人開發者而言，在自己搗騰一些小東西時，這樣的版本号規則就更自由了，完全視軟體作者的水準而良莠不齊。

有的作者或許學習過版本相關的知識，知道遵循一些現成的規範，更多的新手比如像我這樣，完全是随毫無規則地在使用版本号。今天開發完一個功能，那就釋出一個版本叫做0.1吧，下午發現個bug并修複之再發個版本0.2吧。如此顯然不好，無規矩不成方圓啊，我們已經飽受各浏覽器不完全遵循W3C規範而帶來的各種跨浏覽器前端問題了，血的教訓，曆史告訴我們，不能讓悲劇重演，是以迫切需要一個好的準則來指導大家更好地使用軟體版本号。

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

是由

Tom Preston-Werner

發起的一個關于軟體版本号的命名規範，關于這個規範詳細的說明可以在

官網

檢視，也可通路其

GitHub項目頁面

，而關于該規範的中文版本，可以通路我

fork的版本

，由官網繁體中文轉換而來，并稍加修改以更符合大陸用語。順便提句，該規範的作者是

Gravatars

創辦者同時是GitHub聯合創始人。你或許不知道gravatar但作為程式員你肯定知道GitHub。

基本規則

顧名思義，語義化的版本就是讓版本号更具語義化，可以傳達出關于軟體本身的一些重要資訊而不隻是簡單的一串數字。

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

1. 主版本号：當你做了不相容的API 修改
2. 次版本号：當你做了向下相容的功能性新增
3. 修訂号：當你做了向下相容的問題修正

先行版（預覽版）版本号及版本編譯資訊可以加到"主版本号.次版本号.修訂号"的後面，作為延伸。

具體規範

具體詳盡的規範可以參見其官網，當然也可以通路中文版本。這裡簡單總結一下。

• 版本号是以點隔開的形式'X.Y.Z' 且XYZ為正整數，數字前面不加0， 也就是說v0.1.0不能寫成v0.10.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。

如何界定正式版1.0.0的釋出

這個正是我在開發自己的jQuery插件時面臨的問題。如上面規範所述，軟體最初開發階段一般以0.1.0開始。當軟體基本正式功能全部完成且測試通過，對外公共API完成可以用于實際線上環境了，則可以形成1.0.0的正式版了。

更多關于本規範的常見問題還是請檢視文檔，上面的FAQ列出的問題很實在，可以解決使用本版本号命名中的疑惑。

參考

• Semver 簡體中文版本： https://github.com/Wayou/semver_zh_CN/blob/master/semver_zh_CN.md https://github.com/Wayou/semverX 11Xzh_CN/blob/master/semver_zh_CN.md
• Semver GitHub項目位址： https://github.com/mojombo/semver https://github.com/mojombo/semver
• semver 官方文檔頁： http://semver.org/ http://semver.org/

​