バージョニングポリシー

React はセマンティック バージョニング (semantic versioning; semver) の原則に従います。

すなわちバージョン番号は x.y.z になります。

• バグ修正をする時、z の番号を変更することでパッチリリースをします（例 15.6.2 から 15.6.3）。
• 新機能追加をする時、y の番号を変更することでマイナーリリースをします（例 15.6.2 から 15.7.0）。
• 破壊的変更をする時、x の番号を変更することでメジャーリリースをします（例 15.6.2 から 16.0.0）。

メジャーリリースには新機能を含むことができ、全てのリリースにバグ修正を含められます。

マイナーリリースは、最も一般的なリリースです。

このバージョニングポリシーは Next と Experimental チャンネルのプレリリースビルドには適用されません。プレリリースについての詳細

破壊的変更

破壊的変更は誰にとっても不便なので、私たちはメジャーリリースを最小限にするようにしています。例えば React 15 は 2016 年 4 月にリリースされており、React 16 は 2017 年の 9 月にリリースされています。React 17 は 2020 年 10 月にリリースされました。

その代わり、新機能のリリースをマイナーバージョンでしています。つまりマイナーリリースは控えめな名前にも関わらず、メジャーリリースよりしばしば興味深く魅力的です。

安定性への取り組み

React が徐々に変化していく中で、私たちは新機能を取り入れるために必要な労力を最小限にするようにしています。別のパッケージに入れることはあっても、可能な限り古い API が動作するように保ちます。例えばミックスインは長年推奨されていませんが create-react-class を通じて今日までサポートされており、多くのレガシーコードが安定してそれらを継続使用しています。

100 万人を超える開発者が React を使用し、合わせると何百万ものコンポーネントを管理しています。Facebook のコードベースだけでも 5 万以上の React コンポーネントがあります。なので React はできるだけ簡単に新バージョンにアップグレードできるようにする必要があります。もし移行手段なしに React へ大きな変更を行えば、開発者は古いバージョンにとどまるでしょう。私たちはアップグレード方法を Facebook 自体でテストしています。10 人以下の私たちのチームが単独で 5 万以上のコンポーネントをアップデートできるなら、React を使用している全ての人にとって管理しやすいアップグレードであると見込めます。多くの場合、私たちはコンポーネントの構文をアップグレードするための自動化スクリプトを書き、オープンソースのリリースに含め誰でも使用できるようにしています。

警告による段階的アップグレード

React の開発ビルドは多くの有益な警告を含みます。可能な限り、私たちは将来の破壊的変更に備える警告を追加します。最新のリリースでもしあなたのアプリが警告を出さないのであれば、次期メジャーリリースとの互換性があるでしょう。これによりアプリを 1 つのコンポーネントずつアップグレードすることが可能になります。

開発時の警告はあなたのアプリの実行に影響しません。なので開発ビルドと本番ビルドでアプリの動作は同じであると確信できます。違いは、本番ビルドは警告をロギングしないこと、そして本番ビルドはより効率的に動作すること、の 2 点のみです（万一そうなっていないことに気づいた場合は、issue を作成してください）。

何を破壊的変更とみなすのか？

通常、私たちは下記の変更ではメジャー番号を上げません。

• 開発時の警告。これらは本番環境の動作に影響を与えないので、新しい警告の追加や既存の警告の修正はメジャーバージョンの間で行います。これにより次期の破壊的変更を確実に警告することができるのです。
• unstable_ から始まる API 。これらは、API をまだ信頼することができない、実験的な機能として提供されます。unstable_という接頭語をつけてリリースすることで、より速く開発サイクルを進め、より早く安定した API にすることができます。
• React のアルファバージョンとカナリア (canary) バージョン。新機能を早くテストするために React のアルファバージョンを提供しますが、アルファで学んだことを基に柔軟に変更を加える必要があります。もしこれらのバージョンを使用する場合は、安定板のリリース前に API が変わる可能性に注意してください。
• ドキュメント化されていない API と内部データ構造。もし内部プロパティである __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED や __reactInternalInstance$uk43rzhitjg などにアクセスしたいのであれば保証はされません。自己責任で行ってください。

このポリシーはみなさんの頭痛の種とならないよう、実用的に構成されています。上記の全ての変更のためにメジャーバージョンを上げると、より多くメジャーリリースが必要になり、最終的により多くのバージョニングの問題をコミュニティに対して引き起こすことになります。それは React の改善を私たちが望むほど早くできないことも意味します。

それでも、上記のリストのような変更がコミュニティ内で広域に渡る問題を引き起こすと予想される場合は、私たちは段階的な移行手段を提供するように最善を尽くします。

新機能がない場合でもパッチではなくマイナーリリースになる理由は？

マイナーリリースに新機能がないということはあり得ます。これは semver で許容されており、具体的には「（マイナーバージョンは）非公開のコード内で大きな機能追加や改善があった場合に上げても良い (MAY)。パッチレベルの変更を含んでいても良い (MAY)」ことになっています。

それでも、そのようなリリースがパッチリリースとしてバージョニングされないのは何故かというもっともな疑問が湧いてきます。

答えは、React やその他のソフトウエアに対するあらゆる変更には、想定外にコードが壊れるリスクがあるからです。とあるバグを修正するためのパッチリリースが別のバグを引き起こすという状況を想像してください。開発者を混乱させるだけでなく、将来のパッチリリースに対する信頼を失わせることになります。元の修正が現実には滅多に発生しないバグに対するものだった場合は、特に残念なことになります。

React のリリースにバグを含めないことに関して我々はかなり良い成績を残してきていますが、ほとんどの開発者はパッチリリースは有害な副作用なしに採用できるものと当然に考えているので、パッチリリースに関しては信頼性のハードルがさらに上がります。

このような理由により、我々はパッチリリースを重大なバグやセキュリティの脆弱性の修正のみに利用することにしています。

リリースがあまり本質的でない変更、例えば内部のリファクタリング、実装の詳細の変更、パフォーマンス改善、小さなバグ修正といったものに関する場合、我々は新機能がなくともマイナーバージョンを上げます。