版本策略

本页面描述了我们对 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 Changelog 的 Breaking 和 Removed 部分
• 每个版本博客文章的 Breaking Changes 部分

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

什么是破坏性变更？

我们认为 React Native 的破坏性变更包括：

• 不兼容的 API 变更（即 API 被更改或删除，导致您的代码由于该变更而无法编译/运行）。示例：
  • 任何 JS/Java/Kotlin/Obj-c/C++ API 的更改需要您更改代码才能编译。
  • @react-native/codegen 内部不向后兼容的更改。
• 重大的行为/运行时变更。示例：
  • 属性的布局逻辑发生巨大变化。
• 开发体验的重大变更。示例：
  • 调试功能被完全移除。
• 任何传递依赖项的主版本升级。示例：
  • 将 React 从 18.x 升级到 19.x
  • 在 Android 上将 Target 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。为了鼓励反馈，我们确实支持多个发布频道。

note

本节与在框架、库或开发工具上工作的开发人员最相关。主要使用 React Native 构建面向用户的应用程序的开发人员不需要担心 latest 以外的发布频道。

latest

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

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

next

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

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

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

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

nightly

我们还发布 nightly 发布频道。每夜构建版本每天从 facebook/react-native 的 main 分支发布。每夜构建版本被视为 React Native 的不稳定版本，不建议用于生产。

每夜构建版本遵循版本控制模式 0.80.0-nightly-<DATE>-<SHA>，其中 <DATE> 是每夜构建的日期，<SHA> 是用于发布此每夜构建的提交的 SHA。

每夜构建版本仅供测试目的，我们不保证每夜构建之间的行为不会改变。它们不遵循我们用于 latest/next 版本的 semver 协议。

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