2019獨角獸企業重金招聘Python工程師標準>>>

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

• 為什麼要升級？
• 版本升級規範？
• 那麼多程式，那麼多版本，如何記憶？

一、為什麼要升級？

1. 開源社群與 Issue

之前做過一個專案，當時使用 bootstrap-fileupload 元件處理檔案上傳，發現中文顯示總是亂碼。當時腦子裡有個思維定式：官方的東西怎麼可能會出錯呢，肯定是我自己哪裡寫的有問題？去官方文件將所有屬性都檢查了一遍，網上也搜了下問題都沒能找到答案。最後在原始碼裡 debugger 一步步找問題，發現是由於 windows 上記事本的編碼為 'ANSI'，而 bootstrap-fileupload 設定中文編碼 'gbk' 二者並不匹配導致，修改之後就恢復正常了。我想將這個 Bug 提給官方人員，但不知道怎麼聯絡他們，我甚至在搜尋引擎裡搜尋 bootstrap-fileupload

今年 6 月份接觸 github，第一次感受到 開源社群 的含義：dva 是一個基於 React 的前端框架，公司專案選型時決定用它，技術總監便給了我它的 github 地址 讓我去讀一讀它的文件。

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

現在，比如在 [email protected] 裡發現了一個 Bug，在開源社群裡給官方提了一個 Issue，官方修復後併發布了新版本 [email protected]，只需要下載最新的版本即可愉快的使用，而不是去修改原始碼。

注： 並不是所有專案都是開源的，開源的專案也並不一定就把程式碼放在 Github 上，我找了下 jquery 社群是在 Github 上的，Bootstrao-fileupload 好像並沒找到。

2. 軟體需要持續升級

軟體的每一次升級，或修復之前功能 Bug，或新增新的功能，或在優化了效能，讓程式跑的更快。啥？你還不想更新？當別人的微信升級後可以同時傳送多張照片，你沒升級的版本只能一張張地傳送照片。當別人家的 Webstorm 更新之後啟動只花了 5 s，你使用老的版本啟動卻花了 10 s。你還有什麼理由不更新。

程式或軟體並不是一次性的東西，開發完成就放那不管不顧了。這是個持續改進，持續完善的過程。版本就是軟體更新的歷史節點。一個好的程式會指定良好的版本規則，定期釋出新版本，做一些功能上的改進，並將做了哪些修改告訴明確的告知客戶。

二、版本升級規範？

對於客戶來說，不需要關心軟體是怎麼升級的，他們只關心軟體更新了哪些內容，好不好用。

對於開發人員來說，我們制定版本號，有條不紊的定期升級。如果製作版本號的規則混亂，在管理版本的時候將會及其痛苦。所以，我們遵循著相關規範。

1. 版本號

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

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

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

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

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

2. 版本階段

頭條新聞對於使用者來說叫做軟體，對於開發人員來說叫做程式，以下統稱程式。

光是看版本號，可能對於程式處於什麼狀態並不能完全掌握，此時還需附帶版本階段相關英文單詞來附加說明，格式：版本號-版本階段英文單字。

如看到 [email protected] 就知道 dva 的版本號為 1.3.0，當前處於 公測階段，本身還存在 Bug，給部分使用者體驗，使用者提出 Bug 並全部修復完成後才能正式釋出。

程式版本階段對應英文如下，大家遵守規範，看到英文單詞就這個這個版本當前處於什麼階段。

• alpha 內測階段：該階段主要實現程式功能，通常只在內部開發人員之間交流，該階段存在 Bug 較多，待完善。

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

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

  我猜測應該還是考慮一個穩妥的問題。比如：固定 20 號釋出一個 release 版本，15 號的時候就已經開發完成並測試通過進入 rc 候選階段，如果剩下五天不出叉子，那麼這個 rc 版本就是後面的 release 版本，萬一運氣不好，又測出 Bug，那麼就修改釋出 rc2 版本作為新的候選版本。

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

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

• LTS（Long-Term Support）長期支援版本：該階段相當於上面的 release 版本，基本沒啥大 Bug，可供 node 開發人員長期使用，大概 18 個月才會有一次大更新，也就是說安裝 LTS 版本之後就不會頻繁更新。
• Current 當前階段：在 LTS 階段，如果 node 再新增新的特性或者修復 Bug 怎麼辦？統統放到 Current 階段裡，該階段並不穩定，api 經常會變，對於開發人員來說，並不推薦使用。等到 18 個月會將該階段升級為 LTS 穩定階段。

三、那麼多程式，那麼多版本，如何記憶？

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

1. 開源社群

市面上框架那麼多，你的專案肯定不是每種都用的吧，著重關注專案中使用到的程式版本問題。如我的專案中使用 dva、ant-design 、roadhog 、微信小程式，還有一些開源專案，這些專案並不會每天都有更新，官方勤快一點的每週固定更新一次，懶一點的半個月，一個月左右更新一次。所以我一般每週一去開源社群逛一逛，看看最新動態，社群裡會有更新日誌，沒有日誌的可以去 Issue 庫裡看看又出現了什麼新的問題。

2. 開源中國網站

開源中國社群首頁有一個板塊專門介紹軟體更新資訊，裡面有更新的軟體版本，更新內容，並且涉及面極廣。每天逛一逛再也不用擔心拉下什麼重要更新事項了。

轉載於:https://my.oschina.net/dkvirus/blog/1589150