起初，我不太理解 版本 在程序開發(fā)中起到怎樣的作用。直到上周末與一個朋友聊天時，他的開發(fā)工具 Webstorm 突然罷工，需要激活，我將之前我的激活方式告訴了他，但他回應(yīng)激活失敗，詢問之下才知，他的 Webstorm 使用的是 2016.1 版本，而我給他的激活方式適用 2017.2 版本，我問他為什么不升級工具，他回答只要能用不就成了，干嘛要升級？我一時語塞，不知該如何回答他?；剡^頭我細想了一下，覺得還是有必要升級的，本文主要介紹一下幾點。

• 為什么要升級？
• 版本升級規(guī)范？
• 那么多程序，那么多版本，如何記憶？

一、為什么要升級？

1. 開源社區(qū)與 Issue

之前做過一個項目，當時使用 bootstrap-fileupload 組件處理文件上傳，發(fā)現(xiàn)中文顯示總是亂碼。當時腦子里有個思維定式：官方的東西怎么可能會出錯呢，肯定是我自己哪里寫的有問題？去官方文檔將所有屬性都檢查了一遍，網(wǎng)上也搜了下問題都沒能找到答案。最后在源碼里 debugger 一步步找問題，發(fā)現(xiàn)是由于 windows 上記事本的編碼為 'ANSI'，而 bootstrap-fileupload 設(shè)置中文編碼 'gbk' 二者并不匹配導致，修改之后就恢復正常了。我想將這個 Bug 提給官方人員，但不知道怎么聯(lián)系他們，我甚至在搜索引擎里搜索 bootstrap-fileupload 的官方郵箱。（現(xiàn)在想想有點傻乎乎的）

今年 6 月份接觸 github，第一次感受到 開源社區(qū) 的含義：dva 是一個基于 React 的前端框架，公司項目選型時決定用它，技術(shù)總監(jiān)便給了我它的 github 地址 讓我去讀一讀它的文檔。

在這里，我才曉得原來 dva 的源碼竟然是觸手可及的，而不再是生硬的 dva.min.js 文件。如果發(fā)現(xiàn) Bug，可以去 Issue 庫里提問，官方人員會驗證之后并解決的。在 Issue 庫里你不僅可以提出 Bug，還可以幫忙解決 Bug 然后將修改的內(nèi)容 Pull Request 給官方人員。Issue 庫還有個巨大的好處就是遇到問題去里面找，基本上你遇到的問題其它人都有遇到并解決過，這效率比在百度搜索問題準確性不知高了多少倍。

Dva github 頁面

現(xiàn)在，比如在 Bootstrap-fileupload@1.0.0 里發(fā)現(xiàn)了一個 Bug，在開源社區(qū)里給官方提了一個 Issue，官方修復后并發(fā)布了新版本 Bootstrap-fileupload@1.0.1，只需要下載最新的版本即可愉快的使用，而不是去修改源碼。

注： 并不是所有項目都是開源的，開源的項目也并不一定就把代碼放在 Github 上，我找了下 jquery 社區(qū)是在 Github 上的，Bootstrao-fileupload 好像并沒找到。

2. 軟件需要持續(xù)升級

軟件的每一次升級，或修復之前功能 Bug，或新增新的功能，或在優(yōu)化了性能，讓程序跑的更快。啥？你還不想更新？當別人的微信升級后可以同時發(fā)送多張照片，你沒升級的版本只能一張張地發(fā)送照片。當別人家的 Webstorm 更新之后啟動只花了 5 s，你使用老的版本啟動卻花了 10 s。你還有什么理由不更新。

程序或軟件并不是一次性的東西，開發(fā)完成就放那不管不顧了。這是個持續(xù)改進，持續(xù)完善的過程。版本就是軟件更新的歷史節(jié)點。一個好的程序會指定良好的版本規(guī)則，定期發(fā)布新版本，做一些功能上的改進，并將做了哪些修改告訴明確的告知客戶。

手機軟件更新

二、版本升級規(guī)范？

對于客戶來說，不需要關(guān)心軟件是怎么升級的，他們只關(guān)心軟件更新了哪些內(nèi)容，好不好用。

對于開發(fā)人員來說，我們制定版本號，有條不紊的定期升級。如果制作版本號的規(guī)則混亂，在管理版本的時候?qū)捌渫纯?。所以，我們遵循著相關(guān)規(guī)范。

1. 版本號

在上圖中，可以看到 6.4.7 -> 6.4.8，這是將頭條@6.4.7 版本升級到 @6.4.8 版本。規(guī)定版本號由三部分組成，按照順序分別為主版本號.次級版本號.修訂號。

• 修訂號何時變化？ 當修復一兩個 Bug，改動很小時，將修訂號 +1；

• 次級版本號何時變化？ 當新增一些功能，如頭條新增一個欄目時，將次級版本號 +1，修訂號置 0，就變成了 6.5.0，此時的改動不容忽視，但也不是很大；

• 主版本號何時改變？ 當做了很大的改變，如：變動了頭條欄目的布局，用戶再登錄進去時操作體驗完全改變時修改主版本號+1，此時次級版本號和修訂號置0，變成了 7.0.0。

在開發(fā)人員開發(fā)一個新的程序時，建議命名第一個版本號為 0.1.0 ，以后按照規(guī)則依次遞增，第一個 可用的發(fā)行版本 將主版本號升級為 1.0.0。

2. 版本階段

頭條新聞對于用戶來說叫做軟件，對于開發(fā)人員來說叫做程序，以下統(tǒng)稱程序。

光是看版本號，可能對于程序處于什么狀態(tài)并不能完全掌握，此時還需附帶版本階段相關(guān)英文單詞來附加說明，格式：版本號-版本階段英文單字。

如看到 dva@1.3.0-beta 就知道 dva 的版本號為 1.3.0，當前處于 公測階段，本身還存在 Bug，給部分用戶體驗，用戶提出 Bug 并全部修復完成后才能正式發(fā)布。

版本號附帶英文字母

程序版本階段對應(yīng)英文如下，大家遵守規(guī)范，看到英文單詞就這個這個版本當前處于什么階段。

• alpha 內(nèi)測階段：該階段主要實現(xiàn)程序功能，通常只在內(nèi)部開發(fā)人員之間交流，該階段存在 Bug 較多，待完善。

• beta 公測階段：該階段較 alpha 來說修復不少 Bug，但仍存在隱藏問題。由于內(nèi)部人手有限，先發(fā)布該階段版本讓廣大發(fā)燒友用戶們先做體驗，發(fā)現(xiàn)問題，解決問題，不斷完善。比較熟悉的就如小米發(fā)燒友就會很積極的測試功能。

• rc 候選階段：該階段基本解決完 beta 階段的所有 Bug，算是比較完善的一個版本了，可以發(fā)布給所有用戶使用。該階段與 release 階段相差無幾，那為什么不直接忽略此階段版本呢？

  我猜測應(yīng)該還是考慮一個穩(wěn)妥的問題。比如：固定 20 號發(fā)布一個 release 版本，15 號的時候就已經(jīng)開發(fā)完成并測試通過進入 rc 候選階段，如果剩下五天不出叉子，那么這個 rc 版本就是后面的 release 版本，萬一運氣不好，又測出 Bug，那么就修改發(fā)布 rc2 版本作為新的候選版本。

• release 正式發(fā)行版：啦啦啦啦，正式上線版本，給廣大用戶使用，此時要是再有明顯 Bug 是及其影響用戶體驗，損失用戶量的，該階段可以算是完全體了。

當然，對于用于來說，頻繁的更新版本也是一件很痛苦的事。比如我們使用 node，我們就是用戶，node 官方要是隔三差五就更新一次版本，我們在項目中也需要被迫更新 node 版本，這是難以忍受的。于是，node 推出里兩個版本階段可供選擇。

• LTS（Long-Term Support）長期支持版本：該階段相當于上面的 release 版本，基本沒啥大 Bug，可供 node 開發(fā)人員長期使用，大概 18 個月才會有一次大更新，也就是說安裝 LTS 版本之后就不會頻繁更新。
• Current 當前階段：在 LTS 階段，如果 node 再添加新的特性或者修復 Bug 怎么辦？統(tǒng)統(tǒng)放到 Current 階段里，該階段并不穩(wěn)定，api 經(jīng)常會變，對于開發(fā)人員來說，并不推薦使用。等到 18 個月會將該階段升級為 LTS 穩(wěn)定階段。

Node 官方主頁

三、那么多程序，那么多版本，如何記憶？

在前端開發(fā)中，使用的每個前端框架（Vue or Angular or React or Dva.....）、UI 框架都有自己的版本控制，如何去知道什么框架升級到什么版本有什么新的功能呢？

1. 開源社區(qū)

市面上框架那么多，你的項目肯定不是每種都用的吧，著重關(guān)注項目中使用到的程序版本問題。如我的項目中使用 dva、ant-design 、roadhog 、微信小程序，還有一些開源項目，這些項目并不會每天都有更新，官方勤快一點的每周固定更新一次，懶一點的半個月，一個月左右更新一次。所以我一般每周一去開源社區(qū)逛一逛，看看最新動態(tài)，社區(qū)里會有更新日志，沒有日志的可以去 Issue 庫里看看又出現(xiàn)了什么新的問題。

2. 開源中國網(wǎng)站

開源中國社區(qū)首頁有一個板塊專門介紹軟件更新資訊，里面有更新的軟件版本，更新內(nèi)容，并且涉及面極廣。每天逛一逛再也不用擔心拉下什么重要更新事項了。

開源社區(qū)軟件更新板塊