ISVforce ガイド
j第一世代管理パッケージのパッケージバージョン
パッケージバージョンは、パッケージでアップロードされる一連のコンポーネントを特定する番号です。バージョン番号の形式は majorNumber.minorNumber.patchNumber (例: 2.1.3) です。
管理-リリース済みパッケージを示します。こうしたリリースでは、メジャー番号およびマイナー番号が選択した値に増えます。
一連のアップロードのバージョン番号の順序を次の表に示します。
| アップロード順 | タイプ | バージョン番号 | メモ |
|---|---|---|---|
| 最初のアップロード | 管理-ベータ | 1.0 | 最初の「管理 - ベータ」アップロード。 |
| 2 番目のアップロード | 管理-リリース済み | 1.0 | 「管理-リリース済み」アップロード。バージョン番号は変わりません。 |
| 3 番目のアップロード | 管理-リリース済み | 1.1 | この「管理-リリース済み」アップロードのマイナーリリース番号が変更されています。新しいパッチバージョンをアップロードする場合は、パッチ番号を変更できません。 |
| 4 番目のアップロード | 管理-ベータ | 2.0 | バージョン番号 2.0 の最初の「管理 - ベータ」アップロード。メジャーバージョン番号が更新されています。 |
| 5 番目のアップロード | 管理-リリース済み | 2.0 | 「管理-リリース済み」アップロード。バージョン番号は変わりません。 |
既存の登録ユーザが新しいパッケージをインストールした場合、パッケージ内の各コンポーネントのインスタンスは 1 つだけですが、コンポーネントは古いバージョンをエミュレートできます。たとえば、登録ユーザが Apex クラスを含む管理パッケージを使用するとします。公開者が Apex クラスのメソッドを廃止し、新しいパッケージバージョンをリリースする場合でも、新しいバージョンをインストールした後、登録者は Apex クラスのインスタンスを 1 つのみ使用できます。ただし、この Apex クラスは、古いバージョンの廃止されたメソッドを参照するコードの以前のバージョンをエミュレートできます。
パッケージ開発者は条件付きロジックを Apex クラスとトリガで使用し、異なるバージョンに異なる動作をさせることができます。こうすることで、パッケージ開発者は、コード開発を続けながら以前のパッケージバージョンのクラスとトリガでの既存の動作をサポートし続けることができます。
API を使用してクライアントアプリケーションを開発する場合は、インテグレーションで使用する各パッケージのバージョンを指定できます。