@@ -46,13 +46,13 @@ May 3, 2023 by [Dan Abramov](https://twitter.com/dan_abramov), [Sophie Alpert](h
46
46
47
47
Meta では、` main ` ブランチから React をビルドし、毎週特定のピン留めされたコミットに手動で更新することによって、この問題を解決しています。これはまた、過去数年間にわたって React Native リリースが実施してきたアプローチでもあります。React Native のすべての* 安定版* リリースは、React リポジトリの ` main ` ブランチの特定のコミットにピン留めされています。これにより、React Native は重要なバグ修正を取り込むことができ、フレームワークレベルで新しい React 機能を段階的に採用し、グローバルな React のリリース予定に依存しないようにできます。
48
48
49
- このワークフローを、他のフレームワークや統合済セットアップでも利用可能にしたいと考えているのです。例えば、これにより、React の* 上に作られている* フレームワークが、React 関連の破壊的変更を、それが安定版リリース入る* 前に* 取り込むことができます。これが特に有用なのは、一部の破壊的変更はフレームワークとの結合部分にのみ影響するものであるからです 。これによりフレームワークは semver ルールを破ることなく、そのような破壊的変更を独自にマイナーバージョンを付けてリリースできます。
49
+ このワークフローを、他のフレームワークや統合済セットアップでも利用可能にしたいと考えているのです。例えば、これにより、React の* 上に作られている* フレームワークが、React 関連の破壊的変更を、それが安定版リリース入る* 前に* 取り込むことができます。これが特に有用なのは、一部の破壊的変更はフレームワークとの結合部分にのみ影響するものだからです 。これによりフレームワークは semver ルールを破ることなく、そのような破壊的変更を独自にマイナーバージョンを付けてリリースできます。
50
50
51
51
Canary チャンネルでの継続的リリースにより、より緊密なフィードバックループを実現し、新機能がコミュニティで包括的な検証を確実に受けられるようにすることができます。このワークフローは、JavaScript の標準化委員会である TC39 が[ 番号付きのステージで変更を処理する方法] ( https://tc39.es/process-document/ ) に近いものです。新しい React 機能は、React の安定版でリリースされる前に、React をベースにしたフレームワークにおいて先に利用可能になることがあります。これは、新しい JavaScript 機能が、仕様の公式な一部として批准されるより前に、先にブラウザで利用可能になることと同様です。
52
52
53
53
## なぜ Experimental リリースを使わないのか? {/* why-not-use-experimental-releases-instead* /}
54
54
55
- 技術的には [ Experimental リリース] ( /community/versioning-policy#canary-channel ) を使うことは* 可能* ですが、実験的な API は、安定化への道のりの途中でで大幅な変更が行われる(または完全に削除される)ことがあるため、実験的リリースを本番環境で使用することはお勧めしません。Canary リリースにも(どんなリリースでもそうであるように)誤りが含まれることはありますが、今後はこのブログで Canary における破壊的変更を告知する予定です。 Canary は、Meta が社内で実行しているコードに最も近いため、一般的には比較的安定していると考えられます。ただし、バージョンを固定して、ピン留めされたコミットを変更する際には手作業で GitHub のコミットログを確認する必要があります。
55
+ 技術的には [ Experimental リリース] ( /community/versioning-policy#canary-channel ) を使うことは* 可能* ですが、実験的な API は、安定化への道のりの途中でで大幅な変更が行われる(または完全に削除される)ことがあるため、実験的リリースを本番環境で使用することはお勧めしません。Canary リリースにも(どんなリリースでもそうであるように)誤りが含まれることはありますが、今後はこのブログで Canary における破壊的変更を告知する予定です。Canary は、Meta が社内で実行しているコードに最も近いため、一般的には比較的安定していると考えられます。ただし、バージョンを固定して、ピン留めされたコミットを変更する際には手作業で GitHub のコミットログを確認する必要があります。
56
56
57
57
** React を統合済セットアップ(フレームワークなど)以外で使用しているほとんどの人々は、Stable リリースを引き続き使用することになると考えています** 。ただし、フレームワークを開発している場合は、特定のコミットにピン留めされた React の Canary バージョンをバンドルし、自分のペースで固定バージョンを更新していくことを検討してください。これによる利点は、過去数年間 React Native で行われてきたことと同様に、完成された個々の React 機能やバグ修正をユーザに対して早期に、かつ自身のリリーススケジュールに基づいて提供できるようになることです。デメリットとしては、取り込まれる React のコミットを自身で確認し、リリースに含まれる React の変更に対してユーザに伝えるための追加の責任が生じるということです。
58
58
@@ -74,7 +74,7 @@ API の文書化についても、Canary に登場する時点で行われる計
74
74
75
75
[ 3 月に発表した] ( /blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components ) ように、React Server Components の規約は確定しており、ユーザ向けの API に関連する大きな破壊的変更はもう起きないと予想しています。しかし、React Server Components のサポートを React の安定版としてリリースすることはまだできません。なぜなら、いくつかの密接に絡み合ったフレームワーク専用の機能(例:[ アセットのローディング] ( /blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#asset-loading ) )にまだ取り組んでおり、そちらでより多くの破壊的変更が発生することが予想されるからです。
76
76
77
- これは、React Server Components はフレームワークによって採用される準備が整っていることを意味します。ただし、次のメジャー React リリースまで、フレームワークがそれらを採用する唯一の方法は、ピン止めされた React の Canary 版と併せてリリースすることです。(React の 2 つのコピーをバンドルしてしまうのを避けるため、これを行いたいフレームワークは、 ` react ` と ` react-dom ` がフレームワークとともにリリースされたバージョン固定済みの Canary に解決 (resolve) されるよう強制し、それをユーザーに説明する必要があります 。例えば Next.js の App Router はこれを行っています。)
77
+ これは、React Server Components はフレームワークによって採用される準備が整っていることを意味します。ただし、次のメジャー React リリースまで、フレームワークがそれらを採用する唯一の方法は、ピン止めされた React の Canary 版と併せてリリースすることです。(React の 2 つのコピーをバンドルしてしまうのを避けるため、これを行いたいフレームワークは、` react ` と ` react-dom ` がフレームワークとともにリリースされたバージョン固定済みの Canary に解決 (resolve) されるよう強制し、それをユーザに説明する必要があります 。例えば Next.js の App Router はこれを行っています。)
78
78
79
79
## 安定版と Canary 版の両方に対してライブラリをテストする {/* testing-libraries-against-both-stable-and-canary-versions* /}
80
80
0 commit comments