社区

版本策略

所有 React 的稳定版本都经过了高水平的测试，并遵循语义化版本控制 (semver)。React 还提供不稳定版本通道，以鼓励对实验性功能的早期反馈。此页面描述了您对 React 版本可以期待的内容。

有关以前版本的列表，请参阅版本页面。

稳定版本

稳定版 React 版本（也称为“最新”发布渠道）遵循语义化版本控制 (semver)原则。

这意味着版本号为x.y.z

  • 发布严重错误修复时，我们会通过更改z数字来进行补丁版本发布（例如：从 15.6.2 到 15.6.3）。
  • 发布新功能或非严重错误修复时，我们会通过更改y数字来进行次要版本发布（例如：从 15.6.2 到 15.7.0）。
  • 发布重大更改时，我们会通过更改x数字来进行主要版本发布（例如：从 15.6.2 到 16.0.0）。

主要版本也可能包含新功能，任何版本都可能包含错误修复。

次要版本是最常见的版本类型。

重大更改

重大更改对每个人来说都很不方便，因此我们尽量减少主要版本的数量——例如，React 15 于 2016 年 4 月发布，React 16 于 2017 年 9 月发布，React 17 于 2020 年 10 月发布。

相反，我们会在次要版本中发布新功能。这意味着尽管次要版本的名称不起眼，但它们通常比主要版本更有趣、更引人注目。

对稳定的承诺

随着时间的推移，我们对 React 进行更改时，会尽量减少利用新功能所需的工作量。如果可能，我们会保持旧 API 的工作状态，即使这意味着将其放在单独的包中。例如，多年来一直不建议使用 mixin，但如今仍支持通过 create-react-class，许多代码库仍在稳定的遗留代码中使用它们。

超过一百万的开发者使用 React，共同维护着数百万个组件。仅 Facebook 的代码库就拥有超过 50,000 个 React 组件。这意味着我们需要尽可能轻松地升级到新版本的 React；如果我们在没有迁移路径的情况下进行重大更改，人们将停留在旧版本上。我们在 Facebook 本身测试了这些升级路径——如果我们不到 10 人的团队可以单独更新 50,000 多个组件，我们希望升级对任何使用 React 的人都能轻松管理。在许多情况下，我们会编写自动化脚本来升级组件语法，然后将其包含在开源版本中供所有人使用。

通过警告进行逐步升级

React 的开发版本包含许多有用的警告。只要有可能，我们就会添加警告以准备将来的重大更改。这样，如果您的应用程序在最新版本上没有警告，它将与下一个主要版本兼容。这允许您一次升级一个组件。

开发警告不会影响应用程序的运行时行为。这样，您可以确信您的应用程序在开发和生产版本之间的行为方式相同——唯一的区别是生产版本不会记录警告，并且效率更高。（如果您发现情况并非如此，请提交问题。）

什么算作重大更改？

总的来说，我们不会因为以下更改而增加主要版本号：

  • 开发警告。由于这些不会影响生产行为，因此我们可能会在主要版本之间添加新的警告或修改现有警告。事实上，这就是我们能够可靠地警告即将发生的重大更改的原因。
  • 以unstable_开头的 API。这些作为实验性功能提供，我们目前还不确定其 API。通过使用unstable_前缀发布这些内容，我们可以更快地迭代并更快地获得稳定的 API。
  • React 的 Alpha 版和 Canary 版。我们提供 React 的 alpha 版本，以便尽早测试新功能，但我们需要灵活地根据我们在 alpha 阶段学到的知识进行更改。如果您使用这些版本，请注意 API 可能会在稳定版本发布之前发生更改。
  • 未记录的 API 和内部数据结构。如果您访问内部属性名称，例如__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED或__reactInternalInstance$uk43rzhitjg，则不提供任何保证。您需自行承担责任。

此策略旨在务实：当然，我们不想给您带来麻烦。如果我们因为所有这些更改而增加主要版本号，我们将最终发布更多主要版本，并最终为社区造成更多版本控制方面的困扰。这也意味着我们无法像我们希望的那样快速改进 React。

也就是说，如果我们预计此列表中的更改会在社区中造成广泛的问题，我们仍然会尽最大努力提供逐步迁移路径。

如果次要版本没有包含新功能，为什么它不是一个补丁？

次要版本可能不包含新功能。语义化版本规范 (semver) 允许这样做，其中规定“[次要版本]如果在私有代码中引入了实质性的新功能或改进，则可以递增。它可以包含补丁级别的更改。”

但是，这确实提出了一个问题，为什么这些版本没有作为补丁进行版本控制。

答案是，对 React（或其他软件）的任何更改都存在以意外方式破坏的风险。想象一下这样一种情况：修复一个错误的补丁版本意外地引入了另一个错误。这不仅会扰乱开发人员的工作，还会损害他们对未来补丁版本的信心。如果原始修复程序针对的是实际上很少遇到的错误，则尤其令人遗憾。

我们在保持 React 版本无错误方面拥有相当不错的记录，但补丁版本对可靠性的要求更高，因为大多数开发人员都假设它们可以在没有不良后果的情况下采用。

出于这些原因，我们将补丁版本仅用于最严重的错误和安全漏洞。

如果版本包含非必要的更改——例如内部重构、对实现细节的更改、性能改进或次要错误修复——即使没有新功能，我们也会增加次要版本号。

所有发布渠道

React 依靠蓬勃发展的开源社区来提交错误报告、打开拉取请求和提交 RFC。为了鼓励反馈，我们有时会共享包含未发布功能的 React 特殊版本。

注意

本节与从事框架、库或开发者工具开发的开发者最为相关。主要使用 React 构建面向用户的应用程序的开发者无需担心我们的预发布渠道。

React 的每个发布渠道都针对不同的用例而设计

  • 最新 (Latest) 适用于稳定、符合 semver 的 React 版本。这是从 npm 安装 React 时获得的版本。这是您今天正在使用的渠道。直接使用 React 的面向用户的应用程序使用此渠道。
  • 金丝雀 (Canary) 跟踪 React 源代码存储库的主分支。可以将这些视为下一个 semver 版本的候选版本。框架或其他精选设置可以选择使用此渠道和固定版本的 React。 您还可以使用金丝雀版本在 React 和第三方项目之间进行集成测试。
  • 实验性 (Experimental) 包括稳定版本中不可用的实验性 API 和功能。这些也跟踪主分支，但启用了其他功能标志。使用此功能在发布新功能之前试用它们。

所有版本都发布到 npm，但只有最新版本使用语义化版本控制。预发布版本（金丝雀和实验性渠道中的版本）的版本是从其内容的哈希值和提交日期生成的，例如金丝雀版本的18.3.0-canary-388686f29-20230503 和实验性版本的0.0.0-experimental-388686f29-20230503。

最新和金丝雀渠道都正式支持面向用户的应用程序，但期望值不同:

  • 最新版本遵循传统的 semver 模型。
  • 金丝雀版本必须固定并且可能包含重大更改。它们存在于希望根据自己的发布计划逐步发布新的 React 功能和错误修复的精选设置（如框架）中。

实验性版本仅用于测试目的，我们不保证版本之间不会发生行为变化。它们不遵循我们用于最新版本发布的 semver 协议。

通过将预发布版本发布到我们用于稳定版本的同一注册表，我们能够利用许多支持 npm 工作流的工具，例如unpkg 和CodeSandbox。

最新渠道

最新渠道用于稳定的 React 版本发布。它对应于 npm 上的latest标签。它是所有发布到实际用户的 React 应用程序的推荐渠道。

如果您不确定应该使用哪个渠道，请选择最新渠道。如果您直接使用 React，这就是您已经在使用的渠道。您可以预期最新渠道的更新非常稳定。版本遵循语义化版本方案，如前面所述。

金丝雀渠道

金丝雀渠道是一个预发布渠道，它跟踪 React 存储库的主分支。我们在金丝雀渠道中使用预发布版本作为最新渠道的候选版本。您可以将金丝雀视为更新更频繁的最新版本的超集。

最新金丝雀版本与最新稳定版本之间的变化程度与您在两个次要 semver 版本之间发现的变化程度大致相同。但是，金丝雀渠道不符合语义化版本控制。您应该预计金丝雀渠道中连续版本之间偶尔会出现重大更改。

除非您遵循金丝雀工作流程，否则不要直接在面向用户的应用程序中使用预发布版本。

Canary 版本在 npm 上发布时带有 canary 标签。版本号根据构建内容的哈希值和提交日期生成，例如 18.3.0-canary-388686f29-20230503。

使用 Canary 通道进行集成测试

Canary 通道也支持 React 与其他项目之间的集成测试。

所有 React 的更改在公开发布之前都会经过广泛的内部测试。但是，React 生态系统中使用了无数的环境和配置，我们不可能对每一个都进行测试。

如果您是第三方 React 框架、库、开发者工具或类似基础设施项目的作者，您可以通过定期对最新更改运行您的测试套件来帮助我们保持 React 对您的用户和整个 React 社区的稳定性。如果您感兴趣，请按照以下步骤操作

  • 使用您首选的持续集成平台设置 cron 作业。CircleCI 和 Travis CI 都支持 cron 作业。CircleCI 和 Travis CI.

  • 在 cron 作业中，使用 npm 上的 canary 标签将您的 React 包更新到 Canary 通道中最新的 React 版本。使用 npm 命令行：

    npm update react@canary react-dom@canary

    或 yarn：

    yarn upgrade react@canary react-dom@canary

  • 针对更新后的包运行您的测试套件。

  • 如果一切顺利，那就太好了！您可以预期您的项目将在下一个次要 React 版本中正常工作。

  • 如果出现意外错误，请通过 提交问题 告知我们。

使用此工作流程的项目是 Next.js。您可以参考他们的 CircleCI 配置 作为示例。

实验性通道

与 Canary 类似，实验性通道是一个预发布通道，跟踪 React 存储库的主分支。与 Canary 不同的是，实验性版本包含尚未准备好广泛发布的其他功能和 API。

通常，Canary 的更新会伴随着相应的实验性更新。它们基于相同的源代码版本，但使用不同的功能标志进行构建。

实验性版本可能与 Canary 和最新版本有很大不同。请勿在面向用户的应用程序中使用实验性版本。您应该预期实验性通道中的版本之间会有频繁的重大更改。

实验性版本在 npm 上发布时带有 experimental 标签。版本号根据构建内容的哈希值和提交日期生成，例如 0.0.0-experimental-68053d940-20210623。

实验性版本中包含什么内容？

实验性功能是指尚未准备好向广大公众发布的功能，在最终确定之前可能会发生巨大变化。有些实验可能永远不会最终确定——我们进行实验的原因是测试提议更改的可行性。

例如，如果在宣布 Hooks 时存在实验性通道，我们会在 Hooks 在最新版本中可用之前的几周将其发布到实验性通道。

您可能会发现针对实验性版本运行集成测试很有价值。这取决于您。但是，请注意，实验性版本甚至比 Canary 版本更不稳定。我们不保证实验性版本之间的任何稳定性。

如何了解更多关于实验性功能的信息？

实验性功能可能已记录也可能未记录。通常，实验不会记录，直到它们即将在 Canary 或最新版本中发布。

如果某个功能未记录，则可能会有一个 RFC。

当我们准备好宣布新的实验时，我们会发布到 React 博客，但这并不意味着我们会宣传每个实验。

您始终可以参考我们公共 GitHub 存储库的 历史记录 以获取完整的更改列表。

上一页鸣谢