本篇文章跟大家介紹一下Node.js中LTS和Current的差別。有一定的參考價值，有需要的朋友可以參考一下，希望對大家有幫助。
2016 年10 月18 日，Node.js v6 LTS (Boron) 發布，這也是Node.js 啟用LTS 發布計畫以來，第一次同時迎來兩個active LTS(v4 與v6）。這系列文章將講述 Node.js v6 LTS 帶來的一系列變化，本篇主要圍繞在 LTS 展開。如果讀者也對 Node.js LTS 的發布流程不了解，可以先閱讀本篇，否則可以直接跳過閱讀下一篇關於 Node.js Core 的變更。
相關推薦：《nodejs 教學》
Node.js LTS 計畫
Node.js core 在Node.js 與io.js 合併後，為了確保發布穩定有序，讓開發者能夠合理安排升級，開始使用LTS（Long Term Support ）來規劃發布週期。第一個 LTS 版本是 v4，發佈於 2015 年 10 月。
在這個規劃下，Node.js 的版本相當於master 分支在特定時間下經過穩定化處理的快照，時間到了就將master 分支上穩定的部分整合起來，發布新的版本，因此Node.js 的發布是以時間的流逝為準，在保證兼容性靠攏的前提下跳版本，而不是以兼容性和新特性的多少為準，這也解釋了為什麼Node.js 的版本看上去跳得那麼快（不是「啊，我們存了這麼多招，可以發新版了！」而是「啊，四月到了該發版了，我們把攢過的大招過一遍，看有什麼夠穩定能加進去的，雖然可能這些招不怎麼大就是了…」）。
值得一提的是，目前的常青瀏覽器/主流JavaScript 引擎/ECMAScript 標準/C 標準也是採用類似的原則，以時間跨度為基準，從主幹上截取穩定特性來進行發布的。
每一個 LTS 都會有一個代號，從元素週期表取元素名，並依照字母表排序，挑選出適合的。 v4 的代號是 Argon(氬)，v6 的代號是 Boron（硼）。
Node.js 的版本命名規則遵循語意化版本（Semantic Versioning），版本號分為三部分，第一個數字（semver-major）增加，表示有不相容的改變；第二個數字（semver-minor）增加，表示有保持相容的新特性；第三個數字（semver-patch）增加，表示有在保持相容性與特性不變的前提下的改動，例如修復了bug 或改進了文件。這個命名規則有利也有弊，此處不贅述，但它的一些矛盾之處使得Node.js 的命名有一些例外，比如安全更新即使會導致不相容，為了能夠更新到所有major 版本，也依然是semver -minor。
一個LTS 的一生
#LTS current: 第一年的四月到十月
目前Node.js 會在每年四月從master 截取分支出來，收集足夠穩定的特性，發布一個major 的偶數版本（例如v6.0.0），作為下一個LTS 的替代品。在當年四月到十月這段 6 個月的期間，這個偶數版本稱為「current」（如 v6.0.0 "current"）。在接受社群回饋後，這個版本會修復 bug，增加新特性，不斷改善，也可能刪除一些相容性影響太大的改進，此時這個版本的 minor 版本會不斷增加。開發者可以利用這段時間，用這個候選 LTS 版本在線下測試自己的應用，並將相容性問題與 bug 回饋給 Node.js 的開發者。
LTS active: 第一年的十月到第三年的四月
到了當年十月，這個偶數版本就會變成LTS（例如v6.9.0 "LTS"），此時它也被稱為"active LTS"。在此後 18 個月的 active 期間，這個版本幾乎不會再有任何不相容的變更，除了安全相關的 OpenSSL 以外其他的依賴（例如 v8）也不會進行大的更新。這段時間內開發者可以將線上的 Node.js 升級到這個穩定的 LTS 版本，並使用 Node.js 的新特性進行迭代。
LTS maintenance: 第三年的四月到第四年的四月
經過 18 個月的 active 時期後，在第三年的四月，這個版本將會迎來最後 12 個月的 maintenance 時期，這個時候它的更新只有安全性更新和 bug 修復。由於Node.js 每年十月出一個LTS，因此在這個版本active 時期的2/3 的節點，就會有一個新的active LTS 誕生（目前就處於v4 LTS 還剩下6 個月的active 時，v6 LTS active 發佈的時間點）。等到它的 active 時期結束時，開發者已經有 6 個月的時間過渡到下一個 active LTS。即使開發者更新的進度比較慢，也還有 12 個月的 maintenance 時間，抓緊升級。 12 個月後，這個 LTS 將會結束它的壽命，不再迎來任何更新。因此，每個偶數版本，都會有 3 年的壽命。
Node.js 應用程式開發者怎麼選擇？
對於追求穩定性的Node.js 應用開發者來說，只需要每年十月一個版本成為active LTS 的時候線上跟進升級即可，也就是每12個月升一次major 版本，每次升級的版本還有18 個月12 個月的壽命，中間跟進minor 和patch 的時候不用太擔心相容問題。目前的推薦是最好在一個 active LTS 出來的 12 個月內完成線上的升級（因為 12 個月後會出下一個 active LTS）。進度落後的話，妥協到 18 個月，這個 LTS 的 active 時期結束前也可以。再趕不上，起碼要在 30 個月內這個版本結束壽命之前升級完，否則連安全更新也沒有了。
擔心直接升級遇到的兼容問題較多的話，則可以在每年四月偶數版本新出來的時候，提前在線下進行測試和升級準備，將問題反饋到社區（當然如果沒空也不需要管這一步驟），並不斷跟進，十月再升線上版本。這樣線上下都是 12 個月升一次 major，只不過時間點不同。雖然線下需要跟進的兼容性問題多了一些，但同時也可以透過回饋讓自己的相容性需求被社群照顧到。
熱衷於嘗試新特性，或不在生產環境使用的實驗性項目，則可以嘗試每年十月發布的奇數 major 版本。每個奇數版本只會維護8 個月，而且不會有像LTS 那樣的兼容性保證，但Node.js 的開發者會利用這個版本為下一個LTS 做準備，因此它會有更多大膽的嘗試，例如更頻繁的v8 更新（意味著更多的ECMAScript 新特性實作以及效能最佳化）。
因此，現在還在線上使用 v4.x 的開發者，已經可以準備升級到 v6.x 了。如果你的線上應用程式還在使用LTS 計畫啟用前發布的版本，如v0.12.x，也最好抓緊升級到v4.x 或以上，因為2016 年12 月之後v0.12.x 將不會再有任何安全性更新，更早的版本就更沒有了，主要是OpenSSL 的漏洞將不會被修復，這些應用程式將會暴露在各種安全風險之下。一旦升級到 v4.x 或更高，今後的升級將會相對容易許多，平時只要記得跟進 minor 或者 patch 即可，或者懶一點的只需要關注安全更新。
這跟 Node.js 的原始碼是怎麼對應的？
首先，Node.js 的 Github Repo 有一個 master 分支，大部分的 commit 是透過 PR 提交到這個分支上的。根據這些 commit 是否改變了相容性或引入了新特性，它們會被打上 semver-major 或 semver-minor 的標籤。
在每年四月前需要準備 LTS 的時候，Node.js 會從 master 分支截取一個新的分支出來，假如這個是 v6，那麼這個分支就叫 v6.x-staging 。之後與這個 LTS 相關的修改/打算進入這個 LTS 的修改，例如 bug 修復等，還是提交 PR 到 master ，但需要加一個 tag lts-watch-v6.x 。
合併到 master 之後，這些變動會被負責發布的人挑出來，合併到 v6.x-staging 。當到了四月的某一天，v6 的第一個版本可以發布的時候，負責發布的人會創建一個 v6.x 分支，從 v6.x-staging 再挑出變更合併進來。從四月到十月，所有 v6 的修改，無論是 minor 或 patch，依然先提交 PR 到 master ，然後再被挑出來合到 v6.x-staging ，發版本時再進入 v6.x 。
這樣，master 總是保留著最新的變動。而其他版本相關的分支，都是從master 上挑出適合發版本的commit，混合出來的縮影， v6.x-staging 保留著v6.x LTS 相關的修改， v6.x 保留每一次v6 發布的版本。除了負責處理分支的人以外，其他開發者是不會動這些版本相關的分支的。
更多程式相關知識，請造訪：程式設計影片！ ！
以上是Node.js中LTS和Current有什麼差別的詳細內容。更多資訊請關注PHP中文網其他相關文章！
