我們理解你需要 Angular 框架的穩定性。 穩定性確保可重用的元件與函式庫、教學、工具與既有的實務做法，不會意外變得過時。 穩定性是 Angular 周邊生態系蓬勃發展的關鍵。
我們也與你一樣，需要 Angular 持續演進。 我們致力於確保你建構應用所依賴的基礎持續改進，讓你能跟上 Web 生態系其餘部分的發展與使用者的需求。
本文件記載了我們遵循的實務做法，讓這個尖端的應用程式開發平台在穩定性之間取得平衡。 我們致力於確保未來的變更永遠以可預測的方式引入。 我們希望每一位依賴 Angular 的人，都知道新功能在何時、如何加入，並在過時功能被移除時做好充分準備。
有時候，_破壞性變更_是必要的，例如移除 API 或功能，才能持續創新並跟上不斷演進的最佳實務、相依性的變化，或 Web 平台的轉變。這些破壞性變更會經過本文件淘汰政策中說明的淘汰流程。
為了讓這些轉換盡可能單純，Angular 團隊做出以下承諾：
- 我們努力將破壞性變更的數量降到最低，並在可能時提供遷移工具
- 我們遵循本文件所述的淘汰政策，讓你有時間將應用程式更新到最新的 API 與最佳實務
HELPFUL: 本文件所述的實務做法適用於 Angular 2.0 與之後的版本。 如果你目前使用的是 AngularJS，請參閱從 AngularJS 升級。 AngularJS 是 Angular 所有 v1.x 版本的名稱。
Angular 版本編號
Angular 的版本號代表該版本發布引入的變更程度。 採用語意化版本，能幫助你理解更新到新版本可能造成的影響。
Angular 版本號由三個部分組成：major.minor.patch。
例如，版本 7.2.11 代表主版本 7、次版本 2，以及修訂版本 11。
版本號會依據版本發布所包含的變更程度遞增。
| 變更程度 | 說明 |
|---|---|
| 主要版本發布 | 包含重大的新功能，更新期間預期需要一些但極少的開發者協助。更新到新的主要版本時，你可能需要執行更新指令稿、重構程式碼、執行額外的測試，並學習新的 API。 |
| 次要版本發布 | 包含較小的新功能。次要版本發布完全向後相容；更新期間不需要開發者協助，但你可以選擇修改應用程式與函式庫，開始使用該版本新增的 API、功能與能力。我們會在次要版本中透過擴大支援範圍來更新對等相依性，但不要求專案更新這些相依性。 |
| 修訂版本發布 | 低風險的錯誤修正發布。更新期間不需要開發者協助。 |
HELPFUL: 自 Angular 版本 7 起，Angular 核心與 CLI 的主要版本號已對齊。
這代表在你開發 Angular 應用程式並使用 CLI 時，@angular/core 與 CLI 的版本必須相同。
預覽版本發布
我們會為每個主要版本與次要版本提供「Next」與發行候選版（rc）預先發布，讓你搶先預覽即將推出的內容：
| 預先發布類型 | 說明 |
|---|---|
| Next | 正在積極開發與測試中的版本發布。下一個版本會在發布標籤後附加 -next 標識來表示，例如 8.1.0-next.0。 |
| 發行候選版 | 功能已完整並進入最終測試的版本發布。發行候選版會在發布標籤後附加 -rc 標識來表示，例如版本 8.1.0-rc.0。 |
文件最新的 next 或 rc 預先發布版本可在 next.angular.dev 取得。
版本發布頻率
我們朝著固定的版本發布時程努力，讓你能隨著 Angular 的持續演進，規劃並協調你的更新。
HELPFUL: 日期僅供一般參考，可能會有所變動。
一般而言，預期的版本發布週期如下：
- 每 12 個月發布一個主要版本
- 每個主要版本有 4 到 6 個次要版本
- 幾乎每週發布一個修訂版本與預先發布（
next或rc）建置版本
這樣的發布節奏，讓積極的開發者能在新功能完整開發完成、並通過我們的程式碼審查與整合測試流程後，第一時間取得它們；同時，對偏好在功能經過 Google 與其他使用預先發布建置版本的開發者驗證後再接收的生產環境使用者，也能維持平台的穩定與可靠。
HELPFUL: 在 Angular v22 之前，Angular 的主要版本發布週期為 6 個月，每個主要版本有 1 到 3 個次要版本
支援政策與時程
HELPFUL: 約略日期僅供一般參考，可能會有所變動。
版本發布時程
| 版本 | 日期 |
|---|---|
| v22.1 | 2026-07-27 當週 |
| v22.2 | 2026-09-21 當週 |
| v22.3 | 約 2026 年 11 月 |
| v22.4 | 約 2027 年 1 月 |
| v22.5 | 約 2027 年 3 月 |
| v23.0 | 約 2027 年 6 月 |
支援期間
所有主要版本通常支援 24 個月。
| 支援階段 | 支援期間 | 說明 |
|---|---|---|
| 積極支援 | 12 個月 | 會發布定期排程的更新與修訂 |
| 長期支援（LTS） | 12 個月 | 只會發布重大修正與安全性修補 |
積極支援中的版本
下表提供支援中的 Angular 版本狀態。
| 版本 | 狀態 | 發布日期 | 積極支援結束 | LTS 結束 |
|---|---|---|---|---|
| ^22.0.0 | 積極支援 | 2026-06-03 | 2027-06 | 2028-06 |
| ^21.0.0 | LTS | 2025-11-19 | 2026-06-03 | 2027-06 |
| ^20.0.0 | LTS | 2025-05-28 | 2025-11-19 | 2026-11-28 |
IMPORTANT: Angular v2 到 v19 已不再支援。
LTS 修正
一般而言，一項修正若能解決下列問題之一，就會被考慮納入 LTS 版本：
- 新發現的安全性漏洞、
- 自 LTS 開始以來，由第三方變更（例如新瀏覽器版本）引起的迴歸問題。
淘汰政策
當 Angular 團隊打算移除某個 API 或功能時，會將其標示為 deprecated（已淘汰）。當某個 API 已經過時、被另一個 API 取代，或以其他方式停止提供時，就會發生這種情況。已淘汰的 API 在其淘汰期間內仍然可用，淘汰期間至少持續一個主要版本（約一年）。
為了確保你有充足的時間與明確的更新路徑，我們的淘汰政策如下：
| 淘汰階段 | 說明 |
|---|---|
| 公布 | 我們會在變更記錄中公布已淘汰的 API 與功能。已淘汰的 API 會在文件中以 @deprecated 標註，讓文字編輯器與 IDE 在你的專案相依於這些 API 時提供提示。 |
| 淘汰期間 | 當某個 API 或功能被淘汰時，它至少還會存在於下一個主要版本中（期間至少 12 個月）。在此之後，已淘汰的 API 與功能就可能被移除。淘汰可以在任何版本發布中公布，但已淘汰的 API 或功能的移除，只會發生在主要版本發布中。在已淘汰的 API 或功能被移除之前，會依照 LTS 支援政策維護它，也就是只修正重大與安全性問題。 |
| npm 相依性 | 我們只會在主要版本發布中，進行需要你變更應用程式的 npm 相依性更新。在次要版本發布中，我們會透過擴大支援範圍來更新對等相依性，但不要求專案更新這些相依性，直到未來的主要版本為止。這代表在 Angular 次要版本發布期間，Angular 應用程式與函式庫中的 npm 相依性更新是選擇性的。 |
相容性政策
Angular 是由許多套件、子專案與工具組成的集合。 為了防止意外使用私有 API，並讓你清楚理解本文件所述實務做法的涵蓋範圍，我們記錄了哪些屬於、哪些不屬於我們的公開 API 表面。 詳情請參閱 Angular 支援的公開 API 表面。
為了保證 Angular 的向後相容性，我們在合併任何變更之前，都會執行一系列檢查：
- 單元測試與整合測試
- 比對變更前後公開 API 表面的型別定義
- 執行 Google 內部所有依賴 Angular 的應用程式的測試
對公開 API 表面的任何變更，都會依照前述的版本管理、支援與淘汰政策進行。在例外情況下，例如重大安全性修補，修正可能會引入向後不相容的變更。這類例外情況都會在框架的官方溝通管道上附帶明確通知。
編譯器 ABI 穩定性
除了公開 API 的穩定性之外，Angular 在同一個次要版本的各修訂版本之間，還維持編譯器 ABI（Application Binary Interface，應用程式二進位介面）的穩定性。ABI 指的是 Angular 編譯器產生的程式碼所使用的內部執行期 API 集合（例如以 ɵɵ 為前綴的那些）。這項穩定性確保以 Angular 編譯器 X.Y.A 版本編譯的程式碼，能與 X.Y.B 版本的 Angular 執行期相容。
這項穩定性讓微前端等使用情境得以實現：多個應用程式可以共用單一 Angular 執行期，同時各自以不同的修訂版本獨立建置。請注意，ABI 穩定性在次要版本之間並不保證，因為新功能可能需要變更內部 API 或產生程式碼的格式。
HELPFUL: 雖然我們致力於維持 ABI 相容性，並會將任何破壞視為迴歸問題，但實務上很難在所有版本組合下驗證這種相容性。
破壞性變更政策與更新路徑
破壞性變更會要求你進行額外的作業，因為變更後的狀態與變更前並不向後相容。你可以在相容性政策中找到這條規則的少數例外。破壞性變更的範例包括：移除公開 API、變更 Angular 的其他型別定義、改變呼叫的時機，或更新到 Angular 某個相依性的新版本，而該相依性本身就包含破壞性變更。
為了在 Angular 出現破壞性變更時支援你：
- 我們在移除公開 API 之前，會遵循我們的淘汰政策
- 透過
ng update指令支援更新自動化。它提供程式碼轉換，而且我們通常會事先在 Google 內部數十萬個專案上測試過 - 在「Angular 更新指南」中提供從一個主要版本更新到另一個主要版本的逐步說明
只要符合下列條件，你就可以用 ng update 更新到任何 Angular 版本：
- 你想更新_到_的版本仍在支援期間內。
- 你想更新的來源版本，與你想升級到的版本相差在一個主要版本以內。
例如，只要版本 12 仍在支援期間內，你就可以從版本 11 更新到版本 12。 如果你想跨越多個主要版本更新，請一次以一個主要版本為單位，逐次執行每次更新。 例如，要從版本 10 更新到版本 12：
- 從版本 10 更新到版本 11。
- 從版本 11 更新到版本 12。
開發者預覽
我們偶爾會以「開發者預覽」的標籤引入新的 API。這些 API 功能完整且經過打磨，但我們還沒準備好依照一般的淘汰政策將它們穩定下來。
這可能是因為我們想在穩定化之前，先從真實應用程式收集回饋，或者因為相關文件或遷移工具尚未完全完成。回饋可以透過 GitHub issue 提供，開發者可以在其中分享使用經驗、回報錯誤，或提出改進建議，協助我們完善這項功能。
本文件所述的政策與實務做法，不適用於標示為開發者預覽的 API。這類 API 隨時可能變更，即使是在框架的新修訂版本中也一樣。各團隊應自行評估，使用開發者預覽 API 的好處是否值得承擔一般語意化版本管理之外破壞性變更的風險。
實驗性質
這些 API 可能根本不會成為穩定版，或在成為穩定版之前會有重大變更。
本文件所述的政策與實務做法，不適用於標示為實驗性質的 API。這類 API 隨時可能變更，即使是在框架的新修訂版本中也一樣。各團隊應自行評估，使用實驗性質 API 的好處是否值得承擔一般語意化版本管理之外破壞性變更的風險。