跳到主要内容
版本：下一个

版本策略

此页面描述了我们对 react-native 包遵循的版本策略。

我们通过手动和自动化测试对每个版本的 React Native 进行全面测试，以确保质量不会下降。

React Native 的 stable 频道遵循以下描述的 0.x.y 发布策略。

React Native 还提供了一个 nightly 发布频道，以鼓励对实验性功能进行早期反馈。

此页面描述了我们对 react-native 以及 @react-native 范围内的包的版本号的处理方法。

稳定发布版本​

React Native 定期发布稳定版本。

我们遵循 0.x.y 版本控制方案

  • 突破性更改将在新的次要版本中发布，即我们增加 x 数字（例如：0.78.0 到 0.79.0）。
  • 新功能和 API 也将在新的次要版本中发布，即我们增加 x 数字（例如：0.78.0 到 0.79.0）。
  • 关键错误修复将在新的补丁版本中发布，即我们增加 y 数字（例如：0.78.1 到 0.78.2）。

稳定版本定期发布，最新的版本在 NPM 上标记为 latest。

相同次要版本号下的一系列发布称为次要系列（例如 0.76.x 是 0.76.0、0.76.1、0.76.2 等的次要系列）。

您可以在发布页面阅读更多关于我们对稳定性的承诺。

重大变更​

突破性更改对每个人都不方便，我们正在努力将它们最小化。我们在每个稳定版本中发布的所有突破性更改都将在以下部分突出显示

对于每个突破性更改，我们致力于解释其背后的原因，如果可能提供替代 API，并最小化对最终用户的影响。

什么是突破性更改？​

我们认为以下情况是对 React Native 的突破性更改

  • 不兼容的 API 更改（即 API 被更改或删除，导致您的代码因该更改而无法编译/运行）。示例
    • 任何 JS/Java/Kotlin/Obj-c/C++ API 的更改，需要更改您的代码才能编译。
    • @react-native/codegen 内部不向后兼容的更改。
  • 显著的行为/运行时更改。示例
    • 属性的布局逻辑发生巨大变化。
  • 开发体验的显著变化。示例
    • 调试功能被完全移除。
  • 我们任何传递性依赖项的主要版本升级。示例
    • 将 React 从 18.x 升级到 19.x
    • 将 Android 上的目标 SDK 从 34 升级到 35）。
  • 我们任何支持的平台版本的减少。示例
    • 将 Android 上的最低 SDK 从 21 升级到 23
    • 将最低 iOS 版本升级到 15.1。

我们不认为以下更改是突破性的

  • 修改以 unstable_ 前缀开头的 API：这些 API 公开了实验性功能，我们对其最终形式不确定。通过以 unstable_ 前缀发布这些 API，我们可以更快地迭代并更快地达到稳定的 API。
  • 私有或内部 API 的更改：这些 API 通常以 internal_、private_ 为前缀，或存在于 internal/ 或 private/ 文件夹/包中。虽然由于工具限制，其中一些 API 可能具有公共可见性，但我们不认为它们是我们公共 API 的一部分，因此我们将不事先通知地更改它们。
    • 同样，如果您访问内部属性名称，如 __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED 或 __reactInternalInstance$uk43rzhitjg，则不提供任何保证。您将自负其责。
    • 用 @FrameworkAPI 注解的类也视为内部类。
  • 工具/开发 API 的更改：React Native 的某些公共 API 保留用于与框架和其他工具集成。例如，Metro API 或 React Native DevTools API 的某些部分应该仅由其他框架或工具使用。对这些 API 的更改将直接与受影响的工具讨论，不视为突破性更改（我们不会在发布博客文章中广泛传达这些更改）。
  • 开发警告：由于警告不影响运行时行为，我们可能会在任何版本之间添加新警告或修改现有警告。

如果预期更改会在社区中造成广泛问题，我们仍将尽最大努力为生态系统提供逐步迁移路径。

弃用周期​

随着我们不断开发和演进 React Native，我们编写新的 API，有时需要弃用现有的 API。这些 API 将经历一个弃用周期。

一旦 API 被弃用，它将在接下来的稳定版本中仍然可用。

例如：如果一个 API 在 React Native 0.76.x 中被弃用，它在 0.77.x 中仍然可用，并且不会早于 React Native 0.78.x 被移除。

有时，如果我们觉得生态系统需要更多时间才能从某个 API 迁移，我们决定保留已弃用的 API 更长时间。对于这些 API，我们通常会提供警告，以帮助用户从它们迁移。

发布渠道​

React Native 依赖于一个蓬勃发展的开源社区来提交错误报告、开放拉取请求和提交 RFC。为了鼓励反馈，我们支持多个发布渠道。

注意

本节最相关于从事框架、库或开发工具的开发人员。主要使用 React Native 构建面向用户应用程序的开发人员无需担心除 latest 之外的发布渠道。

最新版本​

latest 适用于稳定、语义版本化的 React Native 版本。这是您从 npm 安装 React Native 时获得的版本。这是您今天已经在使用的渠道。直接使用 React Native 的面向用户应用程序使用此渠道。

我们定期发布更新的 React Native 次要系列，并更新 latest 标签以反映最新的稳定版本。

下一个版本​

在我们声明新的 React Native 版本稳定之前，我们会发布一系列候选版本，从 RC0 开始。这些版本是预发布版本（遵循版本控制方案 0.79.0-rc.0），并在 NPM 上标记为 next。

当新的分支剪切发生，并且 RC 开始在 NPM 和 GitHub 上发布时，最好针对 React Native 的 next 版本测试您的库/框架。

这将确保您的项目将继续与即将发布的 React Native 版本良好运行。

但是，请勿在面向用户应用程序中直接使用预发布/RC 版本，因为它们不被视为生产就绪。

每夜构建​

我们还发布了一个 nightly 发布渠道。夜间版本每天从 facebook/react-native 的 main 分支发布。夜间版本被认为是 React Native 的不稳定版本，不建议用于生产环境。

夜间版本遵循版本控制方案 0.80.0-nightly-<DATE>-<SHA>，其中 <DATE> 是夜间版本的日期，<SHA> 是用于发布此夜间版本的提交的 SHA。

夜间版本仅供测试之用，我们不保证夜间版本之间的行为不会改变。它们不遵循我们用于从最新/下一个版本发布的 semver 协议。

最好设置一个 CI 工作流，每天针对 react-native@nightly 版本测试您的库，以确保您的库将继续与未来的版本一起工作。