Node.jsのLTSとCurrentの違いは何ですか

この記事では、Node.js における LTS と Current の違いを紹介します。一定の参考値があるので、困っている友達が参考になれば幸いです。

2016 年 10 月 18 日に、Node.js v6 LTS (Boron) がリリースされました。これは、Node.js が LTS リリース計画を開始して以来、2 つのバージョンがアクティブになったのもこれが初めてです。 LTS (v4 および v6)。このシリーズの記事では、Node.js v6 LTS によってもたらされる一連の変更について説明します。この記事では主に LTS に焦点を当てます。読者が Node.js LTS のリリース プロセスにまだ慣れていない場合は、最初にこの記事を読んでください。そうでない場合は、Node.js コアの変更に関する次の記事を読むのをスキップできます。

#関連する推奨事項: 「

nodejs チュートリアル 」

Node.js LTS プラン

Node.js コア Node.js と io.js の統合後、安定した秩序あるリリースを確保し、開発者が合理的にアップグレードを手配できるようにするために、LTS (

長期サポート##) # ) リリース サイクルを計画します。最初の LTS バージョンは v4 で、2015 年 10 月にリリースされました。 この計画では、Node.js のバージョンは、特定の時点で安定化した master ブランチのスナップショットに相当し、時間が経過すると、master ブランチの安定した部分が統合されますしたがって、Node.js のリリースは時間の経過に基づいており、互換性や新機能の数ではなく、厳密な互換性を確保することを前提としてバージョンがジャンプする理由も説明されています。 Node.js のバージョンが跳ね上がるようです。とても早いです (「ああ、大きな動きをたくさん保存できたので、新しいバージョンをリリースできる!」ではなく、「ああ、4 月に新しいバージョンをリリースする時期が来た。それでは、やりましょう」十分に安定しているものを確認するために保存した大きな動き。これらのトリックはそれほど大きくないかもしれませんが、追加されました...")。

現在の Evergreen ブラウザ/メインストリーム JavaScript エンジン/ECMAScript 標準/C 標準も同様の原則を採用しており、タイムスパンをベンチマークとして採用し、リリースのためにバックボーンから安定した機能を遮断していることは言及する価値があります。

各 LTS にはコード名が付いています。周期表から元素名を取得し、アルファベット順に並べ替えて、適切なものを選択します。 v4のコード名はArgon(アルゴン)、v6のコード名はBoron(ボロン)です。

Node.js のバージョン命名規則は

Semantic Versioning

(Semantic Versioning) に従っており、バージョン番号は 3 つの部分に分かれており、最初の番号 (semver-major) が増加することで、非互換性が示されます。変更; 2 番目の数字 (semver-minor) は増加し、互換性を維持する新機能があることを示します。3 番目の数字 (semver-patch) は増加し、バグ修正やドキュメントなど、互換性と機能は変更されずに変更が加えられたことを示します。改善されました。この命名規則には利点と欠点があり、ここでは説明しませんが、その矛盾の一部により、Node.js の命名にいくつかの例外が生じます。たとえば、セキュリティ更新により互換性がなくなった場合でも、更新できるようにするためにすべてのメジャー バージョンに対して、それは依然として semver. -minor です。

#LTS の生活

##LTS 現在: 1 年目の 4 月から 10 月まで

現在、Node.js は毎年 4 月にマスターから分岐し、十分な安定した機能を収集し、次の LTS の代替としてメジャーな偶数バージョン (v6.0.0 など) をリリースします。その年の 4 月から 10 月までの 6 か月間、この偶数番号のバージョンは「現行」と呼ばれます (たとえば、v6.0.0「現行」)。コミュニティからのフィードバックを受け入れた後、このバージョンはバグを修正し、新機能を追加し、改善を続けますが、互換性への影響が大きすぎるいくつかの改善点は削除される可能性もあります。現時点では、このバージョンのマイナー バージョンは増加し続けます。開発者はこの時間を利用して、この候補 LTS バージョンを使用してアプリケーションをオフラインでテストし、互換性の問題やバグを Node.js 開発者に報告できます。

LTS アクティブ: 1 年目の 10 月から 3 年目の 4 月まで

その年の 10 月までに、この偶数番号のバージョンが LTS (v6.9.0「LTS」など) になります。 , 現時点では「アクティブLTS」とも呼ばれます。今後 18 か月間、このバージョンに互換性のない変更が加えられることはほとんどなく、セキュリティ関連の OpenSSL 以外の依存関係 (v8 など) が大幅に更新されることはありません。この期間中、開発者はオンラインの Node.js をこの安定した LTS バージョンにアップグレードし、Node.js の新機能を繰り返し使用できます。

LTSメンテナンス：3年目4月～4年目4月

18 か月のアクティブ期間の後、3 年目の 4 月に、このバージョンは最後の 12 か月のメンテナンス期間に入ります。現時点では、その更新にはセキュリティ更新とバグ修正のみが含まれます。 Node.js は毎年 10 月に LTS をリリースするため、このバージョンのアクティブ期間中に新しいアクティブ LTS がノードの 2/3 に誕生します (現在、v4 LTS のアクティブ期間が残り 6 か月ある時点、v6 の時点) LTS アクティブがリリースされたとき)。アクティブ期間が終了するまでに、開発者は次のアクティブ LTS に移行するまでに 6 か月の猶予が与えられます。開発者のアップデートの進捗が遅い場合でも、メンテナンス期間は 12 か月ありますので、できるだけ早くアップグレードしてください。 12 か月後、この LTS は有効期間を終了し、更新を受信しなくなります。したがって、すべての偶数番号のバージョンの寿命は 3 年です。

Node.js アプリケーション開発者はどのように選択しますか?

安定性を追求する Node.js アプリケーション開発者は、バージョンがアクティブになる LTS の毎年 10 月、つまり 12 年ごとのメジャー バージョンになったときに、オンラインでフォローアップしてアップグレードするだけで済みます。は月に 1 回アップグレードされ、各アップグレード バージョンの有効期間は 18 ～ 12 か月です。マイナーおよびパッチをフォローアップするときに、互換性の問題についてあまり心配する必要はありません。現在の推奨事項は、アクティブな LTS がリリースされてから 12 か月以内にオンライン アップグレードを完了するのが最善であるということです (次のアクティブな LTS は 12 か月後にリリースされるため)。予定より遅れている場合は、この LTS のアクティブ期間が終了する 18 か月前までは妥協できます。それでも追いつかない場合は、少なくとも 30 か月以内にこのバージョンの有効期間が終了する前にアップグレードする必要があります。そうしないと、セキュリティ更新プログラムが提供されなくなります。

直接アップグレードによって発生する互換性の問題が心配な場合は、毎年 4 月に偶数番号のバージョンがリリースされるときに、事前にオフラインでテストしてアップグレードし、問題をコミュニティにフィードバックすることができます (もちろん、時間がありません) この手順については心配する必要はありません)、フォローアップを続けて、10 月にオンライン バージョンにアップグレードしてください。このように、オンラインメジャーもオフラインメジャーも12ヶ月に1度昇格しますが、その時点が異なります。オフラインでフォローアップする必要がある互換性の問題はさらにありますが、互換性のニーズにフィードバックを通じてコミュニティが対応してもらうこともできます。

新しい機能を試してみたい場合、または運用環境では使用されない実験的なプロジェクトの場合は、毎年 10 月にリリースされる奇数番号のメジャー バージョンを試すことができます。各奇数バージョンは 8 か月しか維持されず、LTS のような互換性保証はありませんが、Node.js 開発者はこのバージョンを次の LTS に備えるために使用するため、より大胆な試みが行われることになります。 v8 アップデートの頻度が高くなります (ECMAScript の新機能の実装とパフォーマンスの最適化が増加することを意味します)。

したがって、まだ v4.x をオンラインで使用している開発者は、すでに v6.x へのアップグレードの準備をすることができます。オンライン アプリケーションが、LTS プランの開始前にリリースされたバージョン (v0.12.x など) をまだ使用している場合は、v0.12.x はサポートされないため、できるだけ早く v4.x 以降にアップグレードすることをお勧めします。以前のバージョンはもちろん、セキュリティ アップデートもありません。主な理由は、OpenSSL の脆弱性が修正されず、これらのアプリケーションがさまざまなセキュリティ リスクにさらされることです。 v4 にアップグレードしたら。

これは Node.js のソース コードとどのように対応しますか?

まず、Node.js の Github リポジトリには master ブランチがあり、ほとんどのコミットは PR を通じてこのブランチに送信されます。これらのコミットが互換性を変更するか、新しい機能を導入するかに応じて、semver-major または semver-minor というラベルが付けられます。

LTS を毎年 4 月より前に準備する必要がある場合、Node.js は master ブランチから新しいブランチを取得します。これが v6 の場合、このブランチは v6.x-staging と呼ばれます。この LTS に関連するその後の変更、またはバグ修正など、この LTS に入ることが意図された変更は、依然として PR をマスターに送信しますが、タグ lts-watch-v6.x を追加する必要があります。

マスターにマージされた後、これらの変更はリリース責任者によって選択され、v6.x ステージングにマージされます。 4 月のある日、v6 の最初のバージョンがリリースされる準備が整うと、リリース責任者は v6.x ブランチを作成し、v6.x ステージングからの変更をマージします。 4 月から 10 月まで、v6 に対するすべての変更は、マイナーであろうとパッチであろうと、最初にマスターに送信され、その後選択されて v6.x ステージングにマージされ、バージョンがリリースされると v6.x に入力されます。

このようにして、マスターは常に最新の変更を保持します。他のバージョン関連のブランチは、マスターから選択され、リリースに適したコミットを混合する小宇宙です。v6.x ステージングは​​ v6.x LTS 関連の変更を保持し、v6.x は各 v6 リリースのバージョンを保持します。ブランチの処理責任者を除いて、他の開発者はこれらのバージョン関連のブランチに触れることはありません。

プログラミング関連の知識について詳しくは、プログラミング ビデオをご覧ください。 ！

以上がNode.jsのLTSとCurrentの違いは何ですかの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。