バージョニングポリシー

以前のリリースの一覧については、バージョンページをご覧ください。

安定版リリース

安定版の 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 のコードベースだけでも 50,000 を超える React コンポーネントがあります。つまり、React の新しいバージョンへのアップグレードをできるだけ簡単にする必要があります。移行パスなしに大規模な変更を加えると、人々は古いバージョンに固定されてしまいます。これらのアップグレードパスを Facebook 自体でテストします。10 人未満のチームだけで 50,000 以上のコンポーネントを更新できる場合、React を使用している人であれば誰でもアップグレードを管理できることを願っています。多くの場合、コンポーネントの構文をアップグレードするための自動スクリプトを作成し、それを誰もが使用できるようにオープンソースリリースに含めています。

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

React の開発版ビルドには、多くの役立つ警告が含まれています。可能な限り、将来の破壊的な変更に備えて警告を追加します。そうすれば、最新リリースでアプリに警告がない場合は、次のメジャーリリースとの互換性が確保されます。これにより、アプリを一度に 1 つのコンポーネントずつアップグレードできます。

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

破壊的な変更とみなされるものは？

一般的に、以下に対する変更では、メジャーバージョンの番号を上げません。

• 開発版の警告。これらは本番環境での動作に影響を与えないため、メジャーバージョン間で新しい警告を追加したり、既存の警告を変更したりする場合があります。実際、これにより、今後の破壊的な変更について確実に警告することができます。
• unstable_ で始まる API。これらは、API にまだ自信がない実験的な機能として提供されています。unstable_ プレフィックス付きでリリースすることにより、より迅速に反復処理を行い、より早く安定した API を実現することができます。
• React のアルファ版および Canary 版。新しい機能を早期にテストする方法として、React のアルファ版を提供していますが、アルファ期間中に学習した内容に基づいて変更を加える柔軟性が必要です。これらのバージョンを使用する場合は、安定版リリース前に API が変更される可能性があることに注意してください。
• ドキュメント化されていない API および内部データ構造。__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED や __reactInternalInstance$uk43rzhitjg などの内部プロパティ名にアクセスする場合は、保証はありません。自己責任で行ってください。

このポリシーは実用的になるように設計されています。確かに、ユーザーに頭痛の種を抱えてほしくありません。これらの変更すべてでメジャーバージョンを上げた場合、より多くのメジャーバージョンをリリースすることになり、最終的にはコミュニティにとってより多くのバージョニングの苦痛を引き起こすことになります。また、React の改善を望むほど早く進めることができないことを意味します。

とは言え、このリストにある変更がコミュニティで広範な問題を引き起こす可能性があると予想される場合は、段階的な移行パスを提供するために最善を尽くします。

マイナーリリースに新機能が含まれていない場合、なぜパッチではないのですか？

マイナーリリースに新機能が含まれない可能性はあります。これは semver によって許可されており、「（マイナーバージョンは）プライベートコード内で実質的な新機能や改善が導入された場合にインクリメントされる場合がある。パッチレベルの変更が含まれる場合がある。」と規定されています。

しかし、これらのリリースが代わりにパッチとしてバージョン管理されないのはなぜかという疑問が生じます。

その答えは、React（または他のソフトウェア）への変更は、予期しない形で壊れるリスクを伴うということです。あるバグを修正するパッチリリースが、誤って別のバグを導入するシナリオを想像してみてください。これは開発者にとって混乱を招くだけでなく、今後のパッチリリースに対する信頼を損なうことにもなります。特に、元の修正が実際にはめったに発生しないバグに対するものであれば、なおさら残念です。

私たちはReactのリリースでバグがない状態を維持することに非常に実績がありますが、パッチリリースは、ほとんどの開発者が悪影響なしに採用できると想定しているため、さらに高い信頼性が求められます。

これらの理由から、パッチリリースは、最も重大なバグとセキュリティの脆弱性に対してのみ予約しています。

リリースに、内部リファクタリング、実装の詳細の変更、パフォーマンスの向上、またはマイナーなバグ修正などの本質的でない変更が含まれている場合、新機能がない場合でもマイナーバージョンを上げます。

すべてのリリースチャネル

Reactは、バグレポートの提出、プルリクエストのオープン、およびRFCの提出を行う、活発なオープンソースコミュニティに依存しています。フィードバックを奨励するために、リリースされていない機能を含むReactの特別なビルドを共有することがあります。

Reactの各リリースチャネルは、明確なユースケース向けに設計されています。

• Latestは、安定したsemver Reactリリース用です。これは、npmからReactをインストールするときに取得するものです。これは、今日すでに使用しているチャネルです。Reactを直接消費するユーザー向けアプリケーションは、このチャネルを使用します。
• Canaryは、Reactソースコードリポジトリのmainブランチを追跡します。これらを次のsemverリリースのリリース候補と見なしてください。フレームワークやその他のキュレーションされた設定では、固定されたバージョンのReactでこのチャネルを使用することを選択できます。また、Reactとサードパーティプロジェクト間の統合テストにCanariesを使用することもできます。
• Experimentalには、安定版リリースでは利用できない実験的なAPIと機能が含まれています。これらもmainブランチを追跡しますが、追加の機能フラグがオンになっています。これを使用して、リリースされる前に今後の機能を試してください。

すべてのリリースはnpmに公開されますが、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リポジトリのmainブランチを追跡するプレリリースチャネルです。Canaryチャネルのプレリリースを、Latestチャネルのリリース候補として使用します。Canaryは、より頻繁に更新されるLatestのスーパーセットと考えることができます。

最新のCanaryリリースと最新のLatestリリースの間の変更の程度は、2つのマイナーなsemverリリースの間で見られるものとほぼ同じです。ただし、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リリースでも動作すると予想できます。

• もし何か予期せぬ問題が発生した場合は、issueを提出して、私たちに知らせてください。

このワークフローを使用しているプロジェクトの例としてNext.jsがあります。彼らのCircleCI構成を参考にしてください。

Experimentalチャネル

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

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

Experimentalリリースは、CanaryおよびLatestへのリリースとは大きく異なる場合があります。ユーザー向けのアプリケーションでExperimentalリリースを使用しないでください。Experimentalチャネルのリリース間では、頻繁な破壊的な変更が予想されます。

Experimentalのリリースは、npmでexperimentalタグ付きで公開されます。バージョンは、ビルドの内容のハッシュとコミット日を基に生成されます。例：0.0.0-experimental-68053d940-20210623。

Experimentalリリースには何が含まれていますか？

Experimental機能は、広く一般公開する準備ができていないものであり、最終決定される前に大幅に変更される可能性があります。一部の実験は最終決定されない可能性があります。実験を行う理由は、提案された変更の実現可能性をテストするためです。

たとえば、Hooksを発表したときにExperimentalチャネルが存在していた場合、HooksをLatestで利用可能にする数週間前にExperimentalチャネルにリリースしていたでしょう。

Experimentalに対して統合テストを実行することが有益であると考えるかもしれません。それはあなた次第です。ただし、ExperimentalはCanaryよりもさらに不安定であることに注意してください。Experimentalリリース間での安定性は保証されません。

Experimental機能についてさらに詳しく知るにはどうすればよいですか？

Experimental機能はドキュメント化されている場合とそうでない場合があります。通常、実験はCanaryまたはLatestで出荷される寸前までドキュメント化されません。

機能がドキュメント化されていない場合、RFCが付属している場合があります。

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

変更の包括的なリストについては、常に公開されているGitHubリポジトリの履歴を参照できます。