バージョン: Next

バージョニングポリシー

このページでは、`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 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の一部は、ツールチェーンの制約により公開されている場合がありますが、これらは公開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が非推奨になると、次の安定版リリースでも引き続き利用できます。

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

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

リリースチャネル

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

注

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

次期バージョン

新しいReact Nativeリリースが安定版であると宣言する前に、RC0から始まる一連のリリース候補を公開します。これらのバージョンはプレリリースバージョン（バージョニングスキーマ`0.79.0-rc.0`に従う）であり、NPMでは`next`としてタグ付けされます。

新しいブランチカットが行われ、RCがNPMとGitHubで公開され始めたら、ライブラリ/フレームワークをReact Nativeの`next`バージョンに対してテストすることをお勧めします。

これにより、プロジェクトが今後のReact Nativeバージョンでも正常に動作し続けることが保証されます。

ただし、プレリリース版/RC版は本番環境での使用には適さないため、ユーザー向けアプリケーションで直接使用しないでください。

ナイトリービルド

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

ナイトリービルドは、`0.80.0-nightly--`というバージョニングスキーマに従います。はナイトリービルドの日付、はそのナイトリービルドの公開に使用されたコミットのSHAです。

ナイトリーリリースはテスト目的のみで提供されており、ナイトリービルド間で動作が変更されないという保証はありません。これらは、最新版/次期版からのリリースで使用するセマンティックバージョニングプロトコルには従いません。

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

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

破壊的変更​

破壊的変更とは何か？​

非推奨サイクル​

リリースチャネル​

最新版​

次期バージョン​

ナイトリービルド​