为社区建设略尽绵薄之力!参与 2020 社区问卷调查!

版本号规则

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

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

  • 出现严重 bug 并修复时,我们会通过修改 z 来发布一个修订版本(如:15.6.2 至 15.6.3)。
  • 当发布新功能修复非严重 bug时,我们会通过修改 y 来发布一个次要版本(如:15.6.2 至 15.7.0)。
  • 当发布破坏性更新时,我们会通过修改 x 来发布一个主版本(如:15.6.2 至 16.0.0)。

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

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

此版本控制策略不适用于 Next 或 Experimental channels 中的预览版。了解更多关于预览版信息

不兼容的改动

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

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

对稳定性的承诺

在我们不断改变 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。

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

如果发布了次要版本但没有引入新特性,那为何不发布修订版?

发布次要版本可能并不会引入新特性。此规则在 semver 有提及如果在私有代码中引入了实质性的新特性或优化,则[次要版本]会增加。它可能包含修订版本的更改。

但是,这带来一个问题,即为什么这些发行版本没有发布为修订版。

对于 React(或其他软件)来说,任何的更改都具有意外破坏的风险。想象一下,发布了修复 bug 的版本,但偶然又引入了另一个 bug。这不仅会对开发人员带来麻烦,还会影响他们对修订版本的信心。如果发布的修订版本针对的是实际开发中极少出现的 bug,则更加令人遗憾。

我们在保证 React 发布的版本没有 bug 方面有着良好的记录,但是修订版发布具有更高标准,因为大多数开发者认为使用这些版本不会带来不利的问题。

基于以上原因,我们仅针对最严重的 bug 和安全漏洞发布修订版本。

如果某个版本包含不必要的更改(例如内部重构,对实现细节的修改,性能优化或较小 bug 的修正),即使没有新特性,我们也会更改次要版本。

Is this page useful?编辑此页面