第二世代管理パッケージの上位パッケージ

上位パッケージについて、また、管理 2GP を使用してどのように線形バージョン管理から脱却できるかについて掘り下げる前に、パッケージのバージョン管理がパッケージアップグレードにどのように影響するかを明らかにしておきましょう。ここでは、先ほど説明した、1.0 → 1.1 → 1.2 → 2.0 というように推移するパッケージのバージョン履歴の例を使用します。顧客は、バージョン 1.0 をインストールし、それ以降の各パッケージバージョンを順にアップグレードすることも、バージョンをスキップして、たとえば 1.0 から 2.0 へとアップグレードすることもできます。低いパッケージバージョン番号から高いパッケージバージョン番号にアップグレードする限り、パッケージアップグレードは成功します。

ですが、開発の過程で、基盤としたくないパッケージバージョンを作成した場合はどうでしょうか? 管理 2GP では、線形バージョン管理から解放され、別のパッケージバージョンを選択して基盤にすることができます。

たとえば、チームがバージョン 1.0 を作成し、次に 1.1、1.2 と作成したとします。ここで、1.2 によって 1.1 が台無しになってしまいました。問題ありません。パッケージバージョンを作成するときに、どのパッケージバージョンが上位パッケージであるかを指定します。つまり、1.2 を破棄して、1.1 を 1.3 の上位パッケージにするわけです。このプロセスは繰り返し行えます。たとえば、図では 1.5 を破棄して、1.4 を基に 1.6 を作成しています。

このように、より複雑でツリー状のバージョン管理を行うことで、2 つ以上の開発チームが並行してパッケージ開発を行うことが可能になるという二次的な効果も生まれます。