Node.js中LTS和Current有哪些區別

這篇文章給大家分享的是有關Node.js中LTS和Current有哪些區別的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

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有哪些區別”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！