跳到主要内容

版本策略

此页面描述了我们对 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 等的次要系列）。

对稳定性的承诺​

为了支持用户升级 React Native 版本，我们承诺维护最新的 3 个次要系列（例如，当 0.78 是最新版本时，维护 0.78.x、0.77.x 和 0.76.x）。

对于这些版本，我们将发布定期更新和错误修复。

您可以在 react-native-releases 工作组中阅读更多关于我们支持策略的信息。

重大更改​

破坏性变更对每个人都不便，我们正在努力将其最小化。我们在每个稳定版本中发布的所有破坏性变更都将在以下位置突出显示：

对于每个破坏性变更，我们承诺解释其背后的原因，如果可能提供替代 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 通常以 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，我们通常会提供警告，以帮助用户从它们迁移。

发布通道​

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

注意

本节与从事框架、库或开发者工具的开发者最为相关。主要使用 React Native 构建面向用户应用的开发者无需担心除最新版本以外的发布渠道。

最新​

latest 用于稳定版、符合 semver 的 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--，其中 是夜间版本的日期， 是用于发布此夜间版本的提交的 SHA。

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

建议设置 CI 工作流程，每天针对 react-native@nightly 版本测试您的库，以确保您的库在未来的版本中也能正常工作。