メタデータコンポーネントを削除する前の考慮事項

ただし、廃止されたコンポーネントがパッケージのアップグレード問題の原因となるシナリオがあります。この問題は廃止されたコンポーネントにのみ関連するものであり、物理削除されたコンポーネントに対しては何もする必要はありません。

廃止されるコンポーネントと削除されるコンポーネントを確認するには、「第二世代管理パッケージからのメタデータコンポーネントの削除」を参照してください。

廃止されたコンポーネントがパッケージのアップグレード問題につながる例として、次のようなシナリオがあります。

1. 登録者 A が管理パッケージのバージョン 1.0 をインストールします。
2. パッケージ開発者が project__c カスタムオブジェクトを削除し���パッケージバージョン 2.0 を作成します。
3. 登録者 A がバージョン 1.0 からバージョン 2.0 にアップグレードし、登録者の組織で project__c が廃止としてマークされるようになりました。登録者が作成した project__c とのインテグレーションは、引き続き機能します。
4. パッケージ開発者はアプリケーションを改良し続け、複数の新しいバージョンをリリースします。
5. バージョン 5.0 の開発中、パッケージ開発者が project__c というコンポーネントをパッケージに追加します。
6. 新しい登録者である登録者 B がバージョン 5.0 のインストールに成功しました。
7. 登録者 A はバージョン 5.0 にアップグレードしようとしましたが、登録者 A のシステム管理者が project__c を組織から削除していないため、インストールが失敗しました。
8. パッケージ開発者が登録者 A のブロックを解除する方法には、次の 2 つがあります。
   1. 登録者 A に project__c への参照をすべて削除するよう依頼し、その後、登録者組織からコンポーネントを削除する。
   2. project__c をパッケージから削除し、新しいパッケージバージョンをリリースする。

パッケージでこのような API 参照名の競合が起きないようにするため、以下にベストプラクティスをいくつか紹介します。

チーム内と社内でコミュニケーションを行う

メタデータを削除する前に、パッケージとそのパッケージを使用しているすべてのパッケージへの影響を評価します。あるパッケージのメタデータを削除すると、そのアクションによって削除されたメタデータを使用しているパッケージの機能が停止する可能性があります。他の開発者がこの変更を認識できるように、チーム内や会社内でコミュニケーションを取ってください。

後続の開発者のためにパッケージの変更をドキュメント化する

パッケージに行われた重大な変更点 (削除されたメタデータコンポーネントの名前など) を内部的にドキュメント化しておくと、後続のパッケージ開発者に、以前使用されていた API 参照名について注意を促すことができます。

登録者に変更について知らせる

削除するコンポーネントがもたらす潜在的な影響について、顧客に説明します。アップグレードしたパッケージのリリースノートで、削除したすべてのコンポーネントをリストして、必要なアクションを顧客に通知します。