Angular 的版本发布
我们知道你希望 Angular 框架具有稳定性（stability）。稳定性可以确保组件与库、教程、工具和现有实践不会突然被废弃。稳定性是让基于 Angular 的生态系统变得繁荣的基石。
我们也和你一样希望 Angular 能持续演进。我们会努力确保这些你用于构建应用的基础能得到持续的改进，并让你能及时同步到 Web 生态系统的其它部分的最新进展，用户需求也是一样。
本文档包含一些我们所遵循的实践，它让我们能为你提供一个前沿的应用开发平台，同时兼顾稳定性。我们会努力确保将来的变化总是以一种可预期的方式引入。我们希望每个 Angular 用户都明白我们将在何时添加以及如何添加新特性，并且为那些将要移除的、准备废弃的特性提前做好准备。
参见更新你的项目，以了解如何把你的应用和库更新到 Angular 的最新版本。
本文档中提及的这些实践适用于 Angular 2.0 及以后的版本。如果你正在使用 AngularJS，请参见从 AngularJS 升级。AngularJS专指 Angular 所有的 v1.x 版本。
Angular 的版本
Angular 的版本号表明本次发布中所引入的变更级别。它使用语义化版本号来帮助你理解升级到新版本时的潜在影响。
Angular 的版本号包括三个部分：major.minor.patch。比如，版本 5.2.9 表示主版本号是 5，小版本号是 2，补丁版本号是 9。
版本号是根据本次发布中包含的变更的级别进行递增的。
- 主版本包含重要的新特性，其中的部分特性在升级时会需要由开发人员提供少量的协助才能完成。当升级到新的主版本时，你可能需要运行升级脚本、重构代码、运行其它测试以及学习新的 API。
- 小版本包含新的小型特性。小版本是完全向后兼容的，在升级期间，不需要开发人员提供协助，但是你可以（可选的）修改你的应用和库，来使用本次发布中新增的 API、特性和能力。我们会扩展平级依赖（peer dependency）中的小版本号范围来更新平级依赖，但并不需要你的项目也更新那些依赖。
- 补丁版本是风险最低的、修 BUG 的版本。在升级期间完全不需要开发人员的协助。
如果你正在同一个主版本内进行升级，那么你可以跳过任何中间版本，直接升级到目标版本。比如，如果你想从 5.0.0 升级到 5.2.9，那么你可以直接升级，而不用先升级到 5.1.0 再升级到 5.2.9。
如果你要从一个主版本升级到另一个，那么我们建议你不要跳过主版本。要遵循升级指南，逐次升级到下一个主版本，在每一个步骤做完后都测试并验证一下。比如，如果你要从 4.x.x 升级到 6.x.x，我们建议你先升级到 5.x.x 中的最新版。在成功升级到 5.x.x 后，你就可以升级到 6.x.x 了。
预发布的预览版（比如 Beta 和 RC 版本）会在版本号后面跟一个横线，再跟一个 beta 或 rc 标识，比如 5.2.9-rc.3。
发布频率
我们会定期发布新版本，以便随着 Angular 的不断演进，你可以提前计划并协调这些升级工作。
通常，你可以期待下列发布周期：
- 每 6 个月一个主版本
- 每个主版本中包含 1~3 个小版本
- 差不多每周一个补丁版本
我们会通过为每个主版本和小版本提供 Beta 发布和 RC 发布，来提高这些发布的质量，并且让你可以预览未来的特性。
这种发布节奏可以让你可以通过 beta 版提前使用新特性，同时，为生产环境下的用户维护本平台的稳定性和可靠性。
发布计划
免责声明：这些日期只是作为一般性的指导，在必要时我们会进行调整，以确保始终提供高质量的平台。
下表中包含下面两个 Angular 主版本的目标发布日期：
日期 | 稳定版 | 兼容性 |
|---|---|---|
September/October 2018?2018-09/10 | 7.0.0 | ^6.0.0 |
March/April 2019?2019-03/04 | 8.0.0 | ^7.0.0 |
兼容性说明：向后兼容性承诺的主要目标是确保在核心框架和核心工具中的变化不会破坏现有组件和应用的生态系统，并且不要给 Angular 应用和组件的开发者带来额外的升级/迁移负担。
支持策略
所有主版本的支持周期都是 18 个月。
- 6 个月的活跃支持，在此期间我们会定期发布更新和补丁，正如前面的发布频率中所说的。
- 12 个月的长期支持（LTS）。在 LTS 期间，只会发布关键性修复和安全补丁。
下表中提供了 Angular 4.0.0 以上的支持状态和一些关键时间点。
版本 | 状态 | 发布日期 | LTS 起始日期 | LTS 结束日期 |
|---|---|---|---|---|
^4.0.0 | LTS | March 23, 20172017-03-23 | September 23, 20172017-09-23 | September 23, 20182018-09-23 |
^5.0.0 | LTS | November 1, 20172017-11-01 | May 1, 20182018-05-01 | May 1, 20192019-05-01 |
^6.0.0 | Active | May 3, 20182018-05-03 | November 3, 20182018-11-03 | November 3, 20192019-11-03 |
弃用策略
"破坏性变更"（比如移除特定的 API 和特性）有时候是必须的，比如创新、让最佳实践与时俱进、变更依赖关系甚至来自 Web 平台自身的变化。
要让这些转变尽可能的简单，我们会给你两项保证：
- 我们会尽量减少破坏性变更的数量，并尽可能提供迁移工具。
- 我们会遵循这里所讲的弃用策略，让你有时间把应用升级到最新的 API 和最佳实践。
为了保证你能有充足的时间和清晰的路径进行升级，我们制定了如下弃用策略：
- 当在变更记录中宣布了准备弃用的特性时。
- 当我们宣布一项弃用时，我们也会同时宣布建议的升级路径。
- 我们会在弃用期间支持使用现有的稳定 API，所以在此期间你的代码仍然能正常工作。
- 我们会支持每个弃用的 API 至少连续两个主版本，这意味着在弃用之前至少有 12 个月的时间。
- 我们只会在主版本中更新你的应用所需的平级依赖。在小版本中，我们通过扩展支持的版本来升级平级依赖。但是我们不需要项目也更新这些依赖 —— 直到下一个主版本为止。
公共 API
Angular 是很多包、子项目和工具的集合。为了防止你意外使用私有 API（这样你才能更清楚的理解哪些 API 会被这里所说的实践所覆盖），我们对公开 API 包含以及不包含哪些 API 进行了文档化。要了解详情，参见 Angular 的公共 API。
任何对公共 API 的修改都适用于上述这些版本、支持和弃用策略。
Angular 实验室（Labs）
Angular 实验室是一项旨在试验新特性并快速迭代它们的尝试。Angular 实验室为 Angular 团队提供了一个探索和试验的安全场所。
Angular 实验室项目尚未准备好供产品环境使用，并且没有任何会把它们带入到产品环境的承诺。本文档中描述的这些策略和实践都不适用于 Angular 实验室中的项目。
本文档系腾讯云开发者社区成员共同维护，如有问题请联系 cloudcommunity@tencent.com
