Angular 发布实践

Angular 的版本与发布

你肯定希望 Angular 框架具有稳定性（stability）。稳定性可以确保组件与库、教程、工具和现有实践不会突然被弃用。稳定性是让基于 Angular 的生态系统变得繁荣的基石。

我们也和你一样希望 Angular 能持续演进。我们会努力确保这些你用于构建应用的基础能得到持续的改进，并让你能及时同步到 Web 生态系统的其它部分的最新进展，用户需求也是一样。

本文档包含一些我们所遵循的实践，它让我们能为你提供一个前沿的应用开发平台，同时兼顾稳定性。我们会努力确保将来的变化总是以一种可预期的方式引入。我们希望每个 Angular 用户都明白我们将在何时添加以及如何添加新特性，并且为那些将要移除的、准备弃用的特性提前做好准备。

Angular 的版本

Angular 的版本号表明本次发布中所引入的变更级别。它使用语义化版本号来帮助你理解升级到新版本时的潜在影响。

Angular 的版本号包括三个部分：​major.minor.patch​。比如，版本 7.2.11 表示主版本号是 7，小版本号是 2，补丁版本号是 11。

版本号是根据本次发布中包含的变更的级别进行递增的。

变更级别	详情
主版本	包含重要的新特性，其中的部分特性在升级时会需要由开发人员提供少量的协助才能完成。当升级到新的主版本时，你可能需要运行升级脚本、重构代码、运行其它测试以及学习新的 API。
小版本	包含新的小型特性。小版本是完全向后兼容的，在升级期间，不需要开发人员提供协助，但是你可以（可选的）修改你的应用和库，来使用本次发布中新增的 API、特性和能力。我们会扩展库的对等依赖（peer dependency）中的小版本号范围来更新库同级，但并不需要你的项目也更新那些依赖。
补丁版本	风险最低的、修 BUG 的版本。在升级期间完全不需要开发人员的协助。

注意：
从 Angular 版本 7 开始，Angular Core 和 CLI 的主要版本已对齐。这意味着在开发 Angular 应用程序时使用的 ​@angular/core​ 和 CLI 的版本必须相同。

所支持的升级路径

你可以 ​ng update​ 到任何版本的 Angular，前提是满足以下条件：

• CLI 支持你要更新到的版本。
• 你要更新“自”的版本是受支持的主要版本之一。

比如，你可以从版本 11 更新到版本 12，前提是版本 12 仍受支持。如果要跨多个主要版本进行更新，请每次更新一个主要版本。比如，要从版本 10 更新到版本 12 时：

• 从版本 10 更新到版本 11。
• 从版本 11 更新到版本 12。

预览发布

我们还会通过提供 Next 版和 RC（候选发布）版来让你预览每个即将到来的大版本和小版本。

预发布类型	详情
Next	这是正在活跃开发和测试中的发布。Next 版的发布标签带有 -next 后缀，比如 8.1.0-next.0。
RC 候选发布版	一个特性已经完成，正在进行最终测试的版本。RC 版的发布标签带有 -rc 标志，比如 8.1.0-rc.0。

发布频率

我们会定期发布新版本，以便随着 Angular 的不断演进，你可以提前计划并协调这些升级工作。

这些日期仅供一般性参考，如有更改，恕不另行通知。

通常的发布周期如下：

• 每 6 个月一个主版本
• 每个主版本中包含 1~3 个小版本
• 差不多每周一个发行版或预发行版(​next ​或 ​rc​)的补丁版本

这种发布的节奏能让渴望新功能的开发者在这些功能开发开发完成并通过我们的代码审查和集成测试流程后立即就可以使用，同时为那些喜欢在新功能经过 Google 和其他使用预发布版本的开发人员的验证后才采纳的生产环境用户，保持平台的稳定性和可靠性。

支持策略与计划

这些日期仅供一般性参考，如有更改，恕不另行通知。

所有主版本的典型支持周期都是 18 个月。

支持阶段	支持时间	详情
活跃	6 个月	会定期发布更新和补丁
LTS 长期支持版	12 个月	只会发布关键性修复和安全补丁。

下表中提供了目前受支持的 Angular 版本的状态。

版本	状态	发布	停止活跃	LTS 结束
^14.0.0	活跃	2022-06-02	2022-12-02	2023-12-02
^13.0.0	活跃	2021-11-04	2022-06-02	2023-05-04
^12.0.0	LTS	2021-05-12	2021-11-12	2022-11-12

不再为 v2 到 v11 版提供支持。

LTS 修复

作为一个通用的规则，如果解决了下列问题之一，就会考虑对 LTS 版本进行修复：

• 一个新发现的安全漏洞。
• LTS 发布以后，由于第三方更改引起的回归性问题，比如浏览器的新版本。

弃用策略

"重大变更"（比如移除特定的 API 和特性）有时候是必须的，比如创新、让最佳实践与时俱进、变更依赖关系甚至来自 Web 平台自身的变化。

要让这些转变尽可能的简单，我们会给你下列保证：

• 我们会尽量减少重大变更的数量，并尽可能提供迁移工具。
• 我们会遵循这里所讲的弃用策略，让你有时间把应用升级到最新的 API 和最佳实践。

为了保证你能有充足的时间和清晰的路径进行升级，我们制定了如下弃用策略：

弃用阶段	详情
宣布弃用	我们会在变更记录中宣布要弃用的那些 API 和特性。启用的 API 在文档中会显示成带删除线的样式。当我们宣布一项弃用时，我们还会宣布一个建议的升级路径。为便于查找，我们在弃用列表中包含一个关于弃用 API 和特性的汇总表。
弃用阶段	当 API 或特性已弃用时，它在接下来的两个主版本中仍然会存在。再往后，弃用的 API 和特性将会进入候选弃用状态。可能会在任何一次发布中宣布弃用，但是只会在主版本中移除已弃用的 API 或特性。除非已弃用的 API 或特性已被移除，否则我们仍然会根据 LTS 支持策略来维护它，也就是说，只会修复严重问题和安全问题。
npm 依赖	在主版本中，我们只会更新那些需要修改你的应用的那些 npm 依赖项。在次要版本中，我们会通过扩展受支持版本范围的方式来更新对等依赖（peerDependencies），但在下一个主版本到来之前，不会强制要求你升级它们。这意味着，在次要版本中，Angular 应用和库中，npm 依赖项的更新是可选的。

公共 API

Angular 是很多包、子项目和工具的集合。为了防止你意外使用私有 API（这样你才能更清楚的理解哪些 API 会被这里所说的实践所覆盖），我们对公开 API 包含以及不包含哪些 API 进行了文档化。要了解详情，参阅 Angular 的公共 API。

任何对公共 API 的修改都适用于上述这些版本、支持和弃用策略。

开发者预览版

有时我们会在“开发者预览”标签下介绍新的 API。这些是功能齐全且经过优化的 API，但我们还没有准备好根据正常的弃用政策来稳定它们。

这可能是因为我们希望在稳定之前从真实应用程序收集反馈，或者因为相关的文档或迁移工具不完全完整。

本文档中描述的政策和实践不适用于标记为 Developer Preview 的 API。此类 API 可以随时更改，即使在框架的新补丁版本中也是如此。团队应该自己决定使用开发者预览版 API 的好处是否值得冒险破坏我们正常使用语义版本控制之外的更改。