バージョニングポリシー
このページでは、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 のバージョンをアップグレードするのをサポートするため、私たちは最新の3つのマイナーシリーズ(例:0.78が最新リリースの場合は 0.78.x、0.77.x、0.76.x)を維持することにコミットしています。
これらのリリースに対して、私たちは定期的なアップデートとバグ修正を公開します。
私たちのサポートポリシーについて詳しくは、react-native-releases ワーキンググループで読むことができます。
破壊的変更
破壊的変更は誰にとっても不便であり、私たちはそれを最小限に抑えようと努めています。各安定版リリースで提供するすべての破壊的変更は、以下で強調表示されます。
- React Native の Changelog の 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 の中には、ツールの制約により public な可視性を持つものもありますが、私たちはそれらを public API の一部とは見なさないため、事前の通知なしに変更します。- 同様に、
__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED
や__reactInternalInstance$uk43rzhitjg
のような内部プロパティ名にアクセスする場合、保証はありません。自己責任でお願いします。 @FrameworkAPI
でアノテーションされたクラスも内部と見なされます。
- 同様に、
- ツール/開発 API の変更:React Native の一部の public API は、フレームワークや他のツールとの統合のために予約されています。たとえば、Metro API や React Native DevTools API の一部は、他のフレームワークやツールによってのみ使用されることになっています。これらの API への変更は、影響を受けるツールと直接協議され、破壊的変更とは見なされません(リリースのブログ記事で広く告知することはありません)。
- 開発時の警告:警告はランタイムの動作に影響しないため、どのバージョン間でも新しい警告を追加したり、既存の警告を変更したりすることがあります。
変更がコミュニティで広範な問題を引き起こすと予想される場合、私たちはエコシステムのために段階的な移行パスを提供するために最善を尽くします。
非推奨サイクル
React Native を開発し進化させ続ける中で、私たちは新しい API を書き、時には既存のものを非推奨にする必要があります。これらの API は非推奨サイクルを経ます。
API が非推奨になると、それは次の安定版リリースでも引き続き利用可能です。
例えば、ある API が React Native 0.76.x で非推奨になった場合、それは 0.77.x でも利用可能であり、React Native 0.78.x より前に削除されることはありません。
エコシステムがそれから移行するためにもっと時間が必要だと感じた場合、私たちは非推奨の API をより長く保持することを決定することがあります。これらの API については、ユーザーが移行するのを助けるために、通常は警告を提供します。
リリースチャンネル
React Native は、バグ報告の提出、プルリクエストのオープン、RFC の提出を行う活発なオープンソースコミュニティに依存しています。フィードバックを奨励するために、私たちはいくつかのリリースチャンネルをサポートしています。
このセクションは、フレームワーク、ライブラリ、または開発者ツールに取り組む開発者に最も関連があります。主にユーザー向けのアプリケーションを構築するために React Native を使用する開発者は、latest 以外のリリースチャンネルについて心配する必要はありません。
latest
latest
は、安定したセマンティックバージョニングの React Native リリース用です。これは、npm から React Native をインストールするときに得られるものです。これは、あなたが今日すでに使用しているチャンネルです。React Native を直接消費するユーザー向けアプリケーションは、このチャンネルを使用します。
私たちは定期的に新しいマイナーシリーズの React Native を公開し、最新の安定バージョンを反映するように latest
タグを更新します。
next
新しい React Native リリースを安定版と宣言する前に、RC0 から始まる一連のリリース候補を公開します。これらのバージョンはプレリリースバージョン(バージョニングスキーマ 0.79.0-rc.0
に従う)であり、NPM 上で next
としてタグ付けされます。
新しいブランチカットが行われ、RC が NPM や GitHub で公開され始めると、あなたのライブラリ/フレームワークを React Native の next
バージョンに対してテストすることをお勧めします。
これにより、あなたのプロジェクトが今後の React Native のバージョンでもうまく機能し続けることが保証されます。
しかし、プレリリース/RC は本番環境での使用には適していないと見なされるため、ユーザー向けアプリケーションで直接使用しないでください。
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 からのリリースで使用するセマンティックバージョニングプロトコルには従いません。
毎日 react-native@nightly バージョンに対してライブラリをテストする CI ワークフローを設定し、ライブラリが将来のリリースでも機能し続けることを確認することをお勧めします。