Angular バージョニングとリリース

Angularフレームワークから安定性を求めていることを認識しています。 安定性により、再利用可能なコンポーネントとライブラリ、チュートリアル、ツール、学習した慣行が予期せず陳腐化することはないことを保証します。 Angularを取り巻くエコシステムが繁栄するためには、安定性が不可欠です。

Angularを進化させ続ける必要性も共有しています。 開発の基盤が継続的に改善され、Webエコシステムやユーザーニーズの最新情報を入手できるよう努めています。

このドキュメントには、安定性を保ちながら、最先端のアプリケーション開発プラットフォームを提供するために従う慣行が含まれています。 将来の変更が常に予測可能な方法で導入されるように努めています。 Angularに依存するすべての人が、新機能がいつどのように追加されるのか、陳腐化した機能が削除されたときにどのように準備するのかを知る必要があります。

破壊的変更 はAPIや機能の削除など、進化するベストプラクティス、依存関係の変更またはWebプラットフォームのシフトに合わせて革新し、最新の状態を維持するために必要となる場合があります。これらの破壊的変更は、非推奨化ポリシーで説明されている非推奨プロセスを経て行われます。

これらの移行をできるだけ簡単にするため、Angularチームは次のコミットメントを行います。

• 破壊的変更の数を最小限に抑え、可能な場合は移行ツールを提供することに尽力しています
• ここに記載されている非推奨ポリシーに従うため、アプリケーションを最新のAPIとベストプラクティスに更新するための時間があります。

Angular のバージョン管理

Angularのバージョン番号は、リリースによって導入される変更のレベルを示します。 セマンティックバージョン管理 を使用すると、新しいバージョンに更新した場合の潜在的な影響を理解するのに役立ちます。

Angularのバージョン番号は、major.minor.patch の3つの部分で構成されています。 たとえば、バージョン7.2.11は、メジャーバージョン7、マイナーバージョン2、パッチレベル11を示します。

バージョン番号は、リリースに含まれる変更のレベルに基づいてインクリメントされます。

プレビューリリース

各メジャーリリースとマイナーリリースの「次」とリリース候補（rc）のプレリリースを提供することにより、今後のリリースをプレビューできます。

最新の next または rc プレビューリリースバージョンのドキュメントは、next.angular.dev で入手できます。

リリース頻度

Angularの継続的な進化に合わせて更新を計画および調整できるように、定期的なリリーススケジュールに向けて取り組んでいます。

一般的に、次のリリースサイクルが期待されます。

• 6か月ごとにメジャーリリース
• 各メジャーリリースに対して1～3回のマイナーリリース
• ほぼ毎週、パッチリリースとプレリリース（next または rc）のビルド

このリリースの頻度は、熱心な開発者にとっては、新機能が完全に開発されコードレビューと統合テストプロセスを通過した時点で新機能にアクセスできます。一方で、Googleやプレリリースビルドを使用する他の開発者によって検証された後に機能を受け取ることを好む開発者にとっては、プラットフォームの安定性と信頼性を維持します。

サポートポリシーとスケジュール

リリーススケジュール

サポート期間

すべてのメジャーリリースは通常、18か月間サポートされます。

アクティブにサポートされているバージョン

次の表は、サポート対象のAngularバージョンのステータスを示しています。

Angularバージョンv2からv15はサポートされなくなりました。

LTSの修正

一般的なルールとして、修正は次のいずれかを解決する場合、LTSバージョン用と見なされます。

• 新たに特定されたセキュリティ脆弱性
• 新しいブラウザバージョンなど、サードパーティの変更によって発生した、LTS開始以降のリグレッション

非推奨化ポリシー

AngularチームがAPIや機能を削除する場合は、非推奨 とマークされます。これは、APIが陳腐化している、別のAPIに置き換えられている、またはその他の理由で廃止されている場合に発生します。非推奨のAPIは、非推奨フェーズの間は使用できます。非推奨フェーズは、少なくとも2つのメジャーバージョン（約1年）続きます。

更新するための十分な時間と明確なパスがあることを確認するために、これが非推奨化ポリシーです。

互換性ポリシー

Angularは、多くのパッケージ、サブプロジェクト、ツールのコレクションです。 プライベートAPIを誤って使用しないように、また、ここで記載されている慣行によって何が対象になるのかを明確に理解できるよう、公開APIサーフェスの対象と対象外を文書化します。 詳細については、Angular のサポート対象のパブリックAPIサーフェスをご覧ください。

Angularの下位互換性を保証するために、変更をマージする前に、一連のチェックを実行します。

• ユニットテストと統合テスト
• 変更の前後のパブリックAPIサーフェスの型定義を比較する
• Angularに依存するGoogleのすべてのアプリケーションのテストを実行する

パブリックAPIサーフェスに対する変更はすべて、前に説明したバージョン管理、サポート、非推奨ポリシーに従って行われます。重要なセキュリティパッチなど、例外的なケースでは、修正によって下位互換性の変更が導入される場合もあります。このような例外的なケースには、フレームワークの公式コミュニケーションチャネルに明示的な通知が添付されます。

破壊的変更ポリシーと更新パス

破壊的変更は、変更後が変更前の状態と下位互換性がないため、作業する必要があります。互換性ポリシーで、このルールのまれな例外を見つけることができます。破壊的変更の例としては、パブリックAPIの削除、Angularの型定義の変更、呼び出しタイミングの変更、またはAngularの依存関係の新しいバージョンへの更新（それ自体に破壊的変更が含まれる）などがあります。

Angularの破壊的変更の場合にサポートするため、次のことを行います。

• パブリックAPIを削除する前に、非推奨化ポリシーに従います
• ng update コマンドを使用した更新自動化をサポートします。Googleで数十万のプロジェクトで事前にテスト済みであることが多いため、コード変換を提供します
• Angularアップデートガイドで、メジャーバージョン間を更新する方法を段階的に説明します。

次の条件が満たされれば、ng update を使用してAngularの任意のバージョンに更新できます。

• 更新先のバージョンがサポートされていること。
• 更新元のバージョンが、 更新先のバージョンのメジャーバージョン1つ以内であること。

たとえば、バージョン12がまだサポートされている場合は、バージョン11からバージョン12に更新できます。 複数のメジャーバージョン間を更新する場合は、一度に1つのメジャーバージョンずつ更新します。 具体的には、バージョン10をバージョン12に更新する手順は次のとおりです。

1. バージョン10をバージョン11に更新します。
2. バージョン11をバージョン12に更新します。

開発者プレビュー

ときどき、「開発者プレビュー」のラベルの下に新しいAPIを導入します。これらは、完全に機能し、洗練されているAPIですが、通常の非推奨ポリシーの下では安定化する準備ができていません。

これは、安定化前に実際のアプリケーションからのフィードバックを収集したい場合、または関連するドキュメントや移行ツールがまだ完全には完成していない場合などです。

このドキュメントに記載されているポリシーと慣行は、開発者プレビューとしてマークされたAPIには適用されません。このようなAPIは、フレームワークの新しいパッチバージョンでも、いつでも変更される可能性があります。チームは、開発者プレビューAPIを使用する利点が、セマンティックバージョンの通常の使用方法ではない破壊的変更のリスクに見合うかどうかを自力で判断する必要があります。

実験的

これらのAPIはまったく安定しない可能性があります。または、安定する前に大幅な変更が行われる可能性もあります。

このドキュメントに記載されているポリシーと慣行は、実験的としてマークされたAPIには適用されません。このようなAPIは、フレームワークの新しいパッチバージョンでも、いつでも変更される可能性があります。チームは、実験的なAPIを使用する利点が、セマンティックバージョンの通常の使用方法ではない破壊的変更のリスクに見合うかどうかを自力で判断する必要があります。