版本号规则
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 的修正），即使没有新特性，我们也会更改次要版本。