バージョニングポリシー

このページでは、react-native パッケージに適用されるバージョニングポリシーについて説明します。

React Native の各バージョンは、品質が低下しないよう、手動テストと自動テストの両方で徹底的にテストされます。

React Native の stable チャネルは、以下に説明する 0.x.y リリースポリシーに従います。

React Native は、実験的な機能に関する早期のフィードバックを促すために、nightly リリースチャネルも提供しています。

このページでは、react-native および @react-native スコープ下のパッケージのバージョン番号に対する私たちのアプローチについて説明します。

安定版リリースバージョン

React Native は定期的に安定版をリリースしています。

私たちは 0.x.y のバージョニングスキーマに従っています。

破壊的変更は新しいマイナーバージョンで提供されます。つまり、x の番号が増加します（例：0.78.0 から 0.79.0）。
新しい機能と API も新しいマイナーバージョンで提供されます。つまり、x の番号が増加します（例：0.78.0 から 0.79.0）。
重大なバグ修正は新しいパッチバージョンで提供されます。つまり、y の番号が増加します（例：0.78.1 から 0.78.2）。

安定版は定期的にリリースされ、最新のものは NPM で latest としてタグ付けされます。

同じマイナー番号の下での一連のリリースは、マイナーシリーズ と呼ばれます（例：0.76.x は 0.76.0、0.76.1、0.76.2 などのマイナーシリーズです）。

リリースに関するページで、私たちの安定性へのコミットメントについて詳しく読むことができます。

破壊的変更

破壊的変更は誰にとっても不便であり、私たちはそれらを最小限に抑えるよう努めています。各安定版リリースで提供されるすべての破壊的変更は、次の場所で強調表示されます。

React Native チェンジログのBreakingおよびRemovedセクション
各リリースブログ投稿のBreaking Changesセクション

それぞれの破壊的変更について、私たちはその背後にある理由を説明し、可能であれば代替 API を提供し、最終ユーザーへの影響を最小限に抑えることにコミットしています。

破壊的変更とは何か？

React Native における破壊的変更と見なされるもの

互換性のない API 変更（つまり、コードがその変更のためにコンパイル/実行できなくなるように変更または削除された API）。例：
- コンパイルするためにコードの変更が必要となる JS/Java/Kotlin/Obj-c/C++ API の変更。
- @react-native/codegen 内の変更で、後方互換性がないもの。
大幅な動作/ランタイムの変更。例：
- プロパティのレイアウトロジックが大幅に変更される。
開発体験における大幅な変更。例：
- デバッグ機能が完全に削除される。
推移的な依存関係のメジャーバージョンアップ。例：
- React を 18.x から 19.x にバージョンアップする。
- Android のターゲット SDK を 34 から 35 にバージョンアップする。
サポートされているプラットフォームバージョンの削減。例：
- Android の最小 SDK を 21 から 23 にバージョンアップする。
- 最小 iOS バージョンを 15.1 にバージョンアップする。

以下の変更は破壊的変更とは見なされません。

unstable_ プレフィックスで始まる API の変更：これらの API は実験的な機能を公開しており、最終的な形状には自信がありません。unstable_ プレフィックスを付けてリリースすることで、より迅速に反復処理を行い、より早く安定した API に到達できます。
プライベートまたは内部 API の変更：これらの API は、internal_、private_ のいずれかのプレフィックスが付いているか、internal/ または private/ フォルダ/パッケージ内に存在することがよくあります。ツール制約によりこれらの API の一部が公開されている場合がありますが、これらは私たちの公開 API の一部とは見なされないため、事前の通知なしに変更されます。
- 同様に、__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED や __reactInternalInstance$uk43rzhitjg のような内部プロパティ名にアクセスしても保証はありません。ご自身の責任でお願いします。
- @FrameworkAPI でアノテーションされたクラスも内部と見なされます。
ツール/開発 API の変更：React Native の一部の公開 API は、フレームワークや他のツールとの統合のために予約されています。例えば、Metro API や React Native DevTools API の一部は、他のフレームワークやツールのみが使用することを想定されています。これらの API の変更は、影響を受けるツールと直接議論され、破壊的変更とは見なされません（リリースブログ投稿で広く伝達されることはありません）。
開発警告：警告はランタイムの動作に影響を与えないため、どのバージョン間でも新しい警告を追加したり、既存の警告を変更したりする場合があります。

変更がコミュニティで広範な問題を引き起こすと予想される場合でも、エコシステムのために段階的な移行パスを提供できるよう最善を尽くします。

非推奨サイクル

React Native の開発と進化を続ける中で、私たちは新しい API を作成し、既存の API を非推奨にする必要がある場合があります。これらの API は非推奨サイクルを経ます。

API が非推奨になると、次の安定版リリースでも引き続き利用可能です。

例：React Native 0.76.x で API が非推奨になった場合、0.77.x でも引き続き利用可能であり、React Native 0.78.x より早く削除されることはありません。

エコシステムがその API から移行するのにより多くの時間が必要だと感じた場合、私たちは非推奨 API をより長く保持することを決定することがあります。そのような API については、通常、ユーザーがそこから移行するのを助けるために警告を提供します。

リリースチャネル

React Native は、バグレポートの提出、プルリクエストのオープン、RFC の提出を行う活発なオープンソースコミュニティに依存しています。フィードバックを奨励するため、いくつかのリリースチャネルをサポートしています。

注

このセクションは、フレームワーク、ライブラリ、または開発ツールに取り組む開発者にとって最も関連性が高いでしょう。主にユーザー向けアプリケーションを構築するために React Native を使用する開発者は、最新版以外のリリースチャネルについて心配する必要はありません。

nightly

nightly リリースチャネルも公開しています。Nightly は、facebook/react-native の main ブランチから毎日公開されます。Nightly は React Native の不安定版と見なされ、本番環境での使用は推奨されません。

Nightly は 0.80.0-nightly-<DATE>-<SHA> のバージョニングスキーマに従います。ここで <DATE> は nightly の日付、<SHA> はこの nightly の公開に使用されたコミットの SHA です。

nightly リリースはテスト目的でのみ提供されており、nightly 間で動作が変更されないという保証はありません。これらは、latest/next からのリリースで使用する semver プロトコルには従いません。

ライブラリが将来のリリースでも引き続き動作することを確認するために、毎日 react-native@nightly バージョンに対してライブラリをテストする CI ワークフローを設定することをお勧めします。

安定版リリースバージョン​

破壊的変更​

破壊的変更とは何か？​

非推奨サイクル​

リリースチャネル​

最新版​

next​

nightly​