コード貢献 - 後方互換性（Backward Compatibility） - 《WordPress開発者リソース》日本語

生産用パブリックAPIの資格

Gutenbergのコードベースは、2種類のパッケージで構成されています：

生産パッケージ：これらはWordPressスクリプトとして出荷されるパッケージです（例：wp-components、wp-editor…）。
開発パッケージ：これらは、サードパーティの開発者がテーマやプラグインをリント、テスト、フォーマット、ビルドするために使用できる開発者ツールで構成されています（例：@wordpress/scrips、@wordpress/env…）。通常、これらはサードパーティプロジェクトのnpm依存関係として消費されます。

後方互換性の保証は生産パッケージにのみ適用され、更新はWordPressのアップグレードを通じて行われます。

生産パッケージは、wpグローバル変数を使用してサードパーティの開発者にAPIを提供します。これらのAPIは、JavaScript関数、変数、Reactコンポーネントである可能性があります。

コンポーネントの名前は変更してはいけません。
コンポーネントのpropsは削除してはいけません。
既存のprop値は引き続きサポートされるべきです。コンポーネントがpropとして関数を受け入れる場合、同じpropに対して新しい型を受け入れるようにコンポーネントを更新できますが、既存の使用を壊してはいけません。
新しいpropsを追加することは許可されています。
React Contextの依存関係は、以前のコンテキスト契約が壊れないことを保証する場合にのみ追加または削除できます。

エディタが読み込まれたときにブロックの既存の使用が壊れたり無効としてマークされたりしてはいけません。
既存のブロックのスタイリングは保証されるべきです。
マークアップの変更は最小限に制限されるべきですが、ブロックが保存されたマークアップを変更する必要がある場合、以前のバージョンを無効にするために、非推奨バージョンのブロックを追加する必要があります。

Reactコンポーネントのツリー内で使用されるクラス名とDOMノードは、パブリックAPIの一部とは見なされず、変更可能です。

これらの変更は、サードパーティのコードのスタイリングや動作に影響を与える可能性があるため、注意して行う必要があります（最初からこれらに依存すべきではありませんが）。可能であれば古いものを保持してください。そうでない場合は、変更を文書化し、開発者ノートを書いてください。

プロジェクトが進化するにつれて、既存のAPIの欠陥が発見されたり、新機能をサポートするために更新が必要になったりします。このような場合、既存のAPIが壊れないように保証し、新しい代替APIを構築しようとします。

サードパーティの開発者が新しいAPIを採用するように促すために、非推奨ヘルパーを使用して、非推奨の説明メッセージを表示し、古いAPIが使用されるたびに代替案を提案できます。

機能が非推奨になった時期をより明確に示してください。ヘルパーメソッドのsinceおよびpluginオプションを使用してください。

例：

deprecated( 'wp.components.ClipboardButton', {
   since: '10.3',
   plugin: 'Gutenberg',
   alternative: 'wp.compose.useCopyToClipboard',
} );

開発者ノートは、WordPressのリリース前にサードパーティの開発者に重要な変更を通知するために、make/coreサイトに公開された投稿です。これらの変更には以下が含まれる可能性があります：

プルリクエストに取り組んでいるときに開発者ノートが必要であることが発見された場合、PRにNeeds Dev Noteラベルを追加します。
可能であれば、なぜ開発者ノートが必要なのかを説明するコメントをPRに追加します。
次のWordPressリリースの最初のベータ版が出荷されたとき、Needs Dev Noteラベルが付けられたリリースに含まれるマージされたPRのリストを確認します。
これらのPRのそれぞれについて、開発者ノートを書き、WordPressリリースリーダーと調整して開発者ノートを公開します。
PRの開発者ノートが公開されたら、PRからNeeds Dev Noteラベルを削除します。