版本号规则

React 遵循语义化版本(semver)原则。

也就是说,若当前版本号为 x.y.z,则:

  • 当发布不兼容的改动时,我们会通过修改 x 来发布一个主版本(如:15.6.2 至 16.0.0)。
  • 当发布新功能时,我们会通过修改 y 来发布一个次版本(如:15.6.2 至 15.7.0)。
  • 当发布问题修复时,我们会通过修改 z 来发布一个修订版本(如:15.6.2 至 15.6.3)。

主版本也可能包含新功能,任何一个版本都可能包含问题修复。

不兼容的改动

不兼容的改动会对所有人造成不便,因此我们会尽可能地减少主版本的发布次数。例如:React 15 在 2016 年 4 月发布,React 16 在 2017 年 9 月发布,而 React 17 在 2019 年才会发布。

实际上,我们会在次版本中发布新功能。次版本相比主版本更加有趣和吸引人,尽管它的名字没这么说。

对稳定性的承诺

在我们不断改变 React 的过程中,我们一直尝试着减少使用新功能的成本。如果情况允许,我们会保留旧的 API,哪怕是将它放在一个独立的 package 中。例如,很多年前我们就不建议使用 mixins,但我们仍然通过 create-react-class 提供对它的支持,使许多项目得以继续在稳定的、旧的代码中使用 mixins。

超过一百万开发者使用 React,维护着数百万个组件。仅 Facebook 代码库就有超过 50000 个 React 组件。这意味着我们需要让升级 React 版本尽可能的简单。如果我们做了很大的变动但没有提供升级方案,人们就会继续使用旧版本。我们在 Facebook 内部会测试这些升级 —— 如果不足 10 人的团队能够独自升级 50000 多个组件,那么任何使用 React 的人都可以轻松升级。在许多情况下,我们会编写自动脚本来帮助更新组件语法,并将这些脚本开源供所有人使用。

根据警告逐渐升级

开发环境的 React 包含许多有帮助的警告。我们会尽可能地添加一些警告以提示未来的不兼容改动。因此,如果你的应用使用的是最新版本而没有收到警告,那么它就会兼容下个主版本。基于此,你可以逐个组件地升级你的应用。

开发环境的警告不会影响你的应用,你的应用在开发环境和生成环境的表现是一致的 —— 唯一的区别是生产环境不会打印出这些警告,并且生产环境的性能更好。(如果你发现了其他的区别,请提交 issue。)

什么算是不兼容的改动?

通常来说,在对下列事情做变更时,我们不会升级主版本号:

  • 开发环境的警告。 由于这些警告不会影响生产环境的表现,我们可能会在同一个主版本中添加或修改警告。实际上这样做可以让我们更好地去提示即将到来的不兼容的改动。
  • unstable_ 开头的 API。 当一些功能还不够稳定时,这些 API 会作为试验性功能提供。通过以 unstable_ 为前缀的方式发布这些 API,我们能够更快地迭代,更早地推出稳定的功能。
  • React 的 alpha 和 canary 版本。 我们提供 alpha 版本的 React 是为了尽早测试新功能,同时我们需要根据 alpha 版本的反馈灵活地做出改动。如果你使用了这些版本,请注意这些 API 在稳定版本发布前可能会有变化。
  • 没有文档的 API 和内部数据结构。 如果你使用了如 __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED__reactInternalInstance$uk43rzhitjg 之类的内部属性,我们不会向你承诺这些属性会一直有效。

这条规则的出发点是务实的:我们不想为你造成不便。如果我们因为这些改动而升级了主版本号,那么会出现更多的主版本,为社区制造更多的版本问题,我们也不能快速地去完善 React。

然而,如果上述列表中的改动会在社区中造成大范围的问题,我们仍会尽全力提供一个逐渐升级的方案。