バージョニングポリシー

安定版リリース

安定版 (Stable) の React リリース（別名 “Latest” リリースチャンネル）は、セマンティックバージョニング (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）。

メジャーリリースには新機能が含まれることもあり、任意のリリースにバグ修正が含まれることがあります。

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

破壊的な変更

破壊的な変更は誰にとっても煩わしいため、メジャーリリースの数は最小限に抑えるようにしています。例えば、React 15 は 2016 年 4 月にリリースされ、React 16 は 2017 年 9 月にリリースされ、React 17 は 2020 年 10 月にリリースされました。

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

安定性へのコミットメント

React に変更を加える際は、新機能を利用するために必要な労力を最小限に抑えるよう努めています。可能な限り古い API を動作させ続けますが、別のパッケージに移動させることはありえます。例えば、ミックスインは何年も前から推奨されていませんが、それらは今日まで create-react-class を通じてサポートされており、多くのコードベースがそれらを安定したレガシーコードで使用し続けています。

100 万人以上の開発者が React を使用しており、合わせれば何百万ものコンポーネントをメンテしています。Facebook のコードベースだけでも、React のコンポーネントは 50,000 個以上存在します。だからこそ私たちは、新バージョンの React へのアップグレードをできるだけ簡単にする必要があるのです。もし私たちが移行手段なしに大きな変更を行えば、人々は古いバージョンから移行できなくなってしまいます。私たちはこれらのアップグレード手段を Facebook 自体でテストしています。もし 10 人もいない我々のチームだけで 50,000 以上のコンポーネントをアップデートできるのであれば、React を使っている誰にとってもそのアップグレードを実行可能であることが期待されます。多くの場合、私たちはコンポーネントの構文をアップグレードするための自動化スクリプトを書き、それをオープンソースのリリースに含めて、誰でも使えるようにします。

警告を通じた段階的アップグレード

React の開発用ビルドには多くの有用な警告が含まれています。可能な限り、我々は将来の破壊的な変更に備えて、あらかじめ警告の追加を行います。ですので、最新リリースであなたのアプリに警告がないなら、それは次のメジャーリリースと互換性があるということです。これにより、あなたはアプリのコンポーネントをひとつずつアップグレードすることができます。

開発時の警告はアプリのランタイムの振る舞いに影響を与えません。そのため、アプリが開発用ビルドと本番用ビルドの間で同じように振る舞うことを確信することができます。唯一の違いは、本番用ビルドは警告をログに出力せず、より効率的に動作することです。（万一それ以外の違いを見つけた場合は問題を報告してください。）

何が破壊的な変更とみなされるのか？

一般的に、我々は以下の変更についてはメジャーバージョン番号を上げません。

• 開発時警告。これらは本番環境での振る舞いに影響を与えないため、我々はメジャーバージョンの途中で新しい警告を追加したり、既存の警告を変更したりすることがあります。実際このおかげで、私たちは将来の破壊的な変更について確実な警告を行えるのです。
• unstable_ で始まる API。これらは私たちがまだ自信を持てていない実験的な機能として提供されています。これらを unstable_ のプレフィックスでリリースすることで、より早くイテレーションを行い、より早く安定した API に到達することができます。
• React のアルファおよび Canary バージョン。新しい機能を早期にテストするための方法として React のアルファバージョンを提供していますが、アルファ期間で学んだことに基づいて変更を加えるための柔軟性が必要です。これらのバージョンを使用する場合、API が安定リリース前に変更される可能性があることに注意してください。
• ドキュメント化されていない API や内部データ構造。もし __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED や __reactInternalInstance$uk43rzhitjg のような内部プロパティ名にアクセスするなら、保証はありません。あなたの自己責任です。

ポリシーがこう設計されているのは実用上の理由です。これが頭痛の種になってほしくないのです。これらすべての変更に対してメジャーバージョンを上げていたのでは、メジャーバージョンのリリースが増えてしまい、結果的にコミュニティにとってバージョニングにまつわる痛みの増加に繋がります。また、私たちが思い通りに素早く React を改善できなくなってしまうことにもなるでしょう。

とはいえ、上記のリストにあるような変更がコミュニティ全体で問題を引き起こすと予想される場合、私たちは段階的な移行パスを提供するために最善を尽くします。

新機能のないリリースをパッチではなくマイナーバージョンでリリースする理由

マイナーリリースに新機能がないこともあります。これは semver によって許可されています：“[a minor version] MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes.”

しかし、そのようなリリースをなぜパッチバージョンとしないのか疑問に感じるかもしれません。

答えは、React（あるいはソフトウェア一般）に対するあらゆる変更は、予期しない形で壊れてしまうリスクを伴うからです。あるバグを修正するためのパッチリリースが、誤って別のバグを引き起こすところを想像してみてください。これは開発者にとって煩わしいというだけでなく、将来のパッチリリースに対する信頼を損なうことにもなります。元の修正が実際にはほとんど遭遇しないバグのためのものである場合、もたらされる結果は特に残念なものとなるでしょう。

React のリリースをバグのない状態に保つことに関しての私たちの実績はかなり良いものではあります。しかしパッチリリースに関しては問題なく採用できることをほとんどの開発者が前提としているため、信頼性に関するハードルはさらに高くなります。

これらの理由から、私たちは非常に重要なバグやセキュリティの脆弱性に対してのみ、パッチリリースを用います。

リリースが、必須ではない変更を含む場合（内部のリファクタリング、実装の詳細の変更、パフォーマンスの改善、またはマイナーなバグ修正など）、新機能がなくともマイナーバージョンを上げます。

全リリースチャンネル

バグレポートの報告、プルリクエストの提出、RFC の提出などについて、React は活発なオープンソースコミュニティを頼りにしています。フィードバックを促すため、ときおり未リリースの機能を含む特別なビルドの React を共有することがあります。

React のリリースチャンネルはそれぞれ異なるユースケースに対応するように設計されています。

• Latest は、安定した、semver に基づく React リリースのためのものです。npm から React をインストールすると得られるものです。これが、あなたが今日すでに使用しているチャンネルです。React を直接使用するユーザ向けアプリケーションは、このチャンネルを使用します。
• Canary は、React ソースコードリポジトリのメインブランチを追跡します。これは、次の semver リリースのためのリリース候補だと考えてください。フレームワークや他の統合済みセットアップは、React のバージョンを固定してこのチャンネルを使用することができます。また、React とサードパーティプロジェクト間の統合テストに Canary を使用することもできます。
• Experimental には、安定リリースでは利用できない実験的な API や機能が含まれています。これらもメインブランチを追跡しますが、追加の機能フラグがオンになっています。リリース前に将来の機能を試すにはこちらを利用します。

すべてのリリースは npm に公開されますが、semver を使用するのは Latest だけです。プレリリース（Canary と Experimental チャンネルにあるもの）は、その内容のハッシュとコミット日から生成されたバージョンになります。例えば、Canary の場合は 18.3.0-canary-388686f29-20230503、Experimental の場合は 0.0.0-experimental-388686f29-20230503 のようになります。

Latest と Canary のチャンネルのいずれも、ユーザ向けアプリケーションでの使用が公式にサポートされるものですが、期待できることが異なります。

• Latest リリースは伝統的な semver モデルに従います。
• Canary リリースはバージョンを固定する必要があり、破壊的な変更を含むことがあります。これらは、自身のリリーススケジュールで React の新機能やバグ修正を段階的にリリースしたい統合済みセットアップ（フレームワークなど）のために存在します。

Experimental リリースはテスト目的のみに提供されており、リリース間での挙動が変わらないことを保証していません。Latest チャンネルのリリースで使用している semver 規約には従いません。

安定版リリースと同じレジストリにプレリリースを公開することで、unpkg や CodeSandbox など、npm ワークフローをサポートする多くのツールを活用できます。

Latest チャンネル

Latest は、安定した React リリースに使用されるチャンネルです。npm の latest タグに対応しています。実際のユーザに提供されるすべての React アプリケーションに対して推奨されるチャンネルです。

どのチャンネルを使用すべきかわからない場合は、Latest を使用してください。すでに React を直接使用している場合、これがあなたの使用しているものです。Latest での更新は非常に安定していると期待できます。先に説明した通り、バージョンはセマンティックバージョニングの仕組みに従います。

Canary チャンネル

Canary チャンネルは、React リポジトリのメインブランチを追跡するプレリリースチャンネルです。Canary チャンネルのプレリリースは、Latest チャンネルのリリース候補として使用します。Canary を、より頻繁に更新される Latest のスーパーセットと考えることができます。

最新の Canary リリースと最新の Latest リリースの間の違いは、概ね semver における 2 つのマイナーリリース間の違いに対応します。ただし Canary チャンネルはセマンティックバージョニングに準拠していません。Canary チャンネルでは連続したリリース間でときおり破壊的な変更が発生することを覚悟してください。

Canary のワークフローに従うのでない限り、ユーザ向けのアプリケーションで直接プレリリースを使用しないでください。

Canary リリースは、npm の canary タグで公開されます。バージョンはビルドの内容のハッシュとコミット日から生成されます。例えば 18.3.0-canary-388686f29-20230503 のようになります。

統合テストのための Canary チャンネルの使用

Canary チャンネルは、React と他のプロジェクト間の統合テストもサポートしています。

React へのすべての更新は、一般に公開される前に広範な内部テストを経ています。しかし、React エコシステム全体で使用されている環境やセットアップは無数にあるため、私たちがすべてをテストすることは不可能です。

もしあなたがサードパーティの React フレームワーク、ライブラリ、開発者ツール、または類似のインフラストラクチャ系のプロジェクトの作者であるなら、定期的にテストスイートを最新の変更に対して実行することで、あなたのユーザとすべての React コミュニティに対して React を安定したものに保つ手助けをしていただけます。興味がある方は、以下の手順に従ってください。

• お好みの継続的インテグレーションプラットフォームを使用して cron ジョブを設定します。cron ジョブは CircleCI と Travis CI の両方でサポートされています。

• cron ジョブ内では、npm の canary タグを使用して、React パッケージを Canary チャンネルの最新の React リリースに更新します。npm cli を使用する場合：

  npm update react@canary react-dom@canary

  または yarn を使用する場合：

  yarn upgrade react@canary react-dom@canary

• 更新されたパッケージに対してテストスイートを実行します。

• すべてのテストが通過した場合はおめでとうございます！ あなたのプロジェクトは次のマイナー React リリースでも動作すると期待できます。

• 何か予期せぬ問題が発生した場合、問題を報告してください。

このワークフローを採用しているプロジェクトのひとつが Next.js です。例として彼らの CircleCI 設定を参照してください。

Experimental チャンネル

Canary と同様に、Experimental チャンネルは React リポジトリのメインブランチを追跡するプレリリースチャンネルです。しかし、Canary とは異なり、Experimental リリースには、広範にリリースする準備が整っていない追加機能と API が含まれています。

通常、Canary に更新がある場合、Experimental にも対応する更新が同時に行われます。これらは同じソースリビジョンに基づいていますが、異なる機能フラグセットを使用してビルドされています。

Experimental リリースは、Canary や Latest へのリリースとは大きく異なる可能性があります。ユーザ向けのアプリケーションで実験的なリリースを使用しないでください。Experimental チャンネルのリリース間では、頻繁に破壊的変更が発生することを覚悟してください。

Experimental のリリースは npm の experimental タグで公開されます。バージョンはビルド内容のハッシュとコミット日から生成され、例えば 0.0.0-experimental-68053d940-20210623 のようになります。

Experimental リリースに含まれるもの

実験的な機能とは、広く公開する準備が整っておらず、最終版に至るまでに大幅に変更される可能性があるものです。実験はあくまで提案された変更の実現可能性を評価するためのものですので、一部の実験は永遠に最終版にならない可能性もあります。

例えば、フックを発表したときに Experimental チャンネルが存在していたなら、Latest で利用可能になる数週間前にフックを Experimental チャンネルにリリースしていたでしょう。

Experimental に対して統合テストを実行することに価値があると感じるかもしれません。これはあなた次第です。ただし、Experimental は Canary よりも安定性が低いことをご了承ください。Experimental リリース間の安定性は一切保証されません。

実験的な機能について詳しく知るには？

実験的機能は文書化される場合もされない場合もあります。通常は、実験は Canary や Latest でリリースする直前まで文書化されません。

機能が文書化されていない場合でも対応する RFC が存在する可能性はあります。

新しい実験を発表する準備が整ったときには React ブログ に投稿しますが、すべての実験を公表するわけではありません。

変更の包括的なリストは、公開 GitHub リポジトリの履歴でいつでも参照できます。