目標は、複数のメジャーバージョンをひとつのスクリプトで実行できることです。
そのため、新しいメジャーバージョン (BC が失われたり、 劇的な機能追加の結果、作者がメジャーバージョンを上げようと考えた場合) は、以下の規約にもとづく新しい名前のパッケージにしなければなりません。 以下のうち、先頭に近い名前のほうが優先されます ('Foo' がパッケージ名、そして 'X' がメジャーバージョン番号です)。
FooX
FoovX
Foo_vX
選択の基準は、現在および将来において、 意味を取り違えたりあいまいになったりする可能性のある名前を避けるということです。 この点に十分注意して、新しいパッケージの名前を決める必要があります。 明らかに、最初のふたつは何らかのあいまいさを残す可能性があります (たとえば、DB2 は IBM DB2 用のパッケージなのか DB のメジャーバージョン 2 なのか? あるいは、IPv4 は IPv4 用のパッケージなのか IP パッケージの四番目のメジャーリリースなのか?)。 これらは、"_" がディレクトリの区切りに対応する (たとえば DB_NestedSet は、DB ディレクトリにある nestedset.php に対応する) という考えかたに反しません。 最後のパターンはあいまいさを残す心配はありませんが、 見栄えがもっとも悪くなります。また、'_' がディレクトリの区切りをあらわすという考えかたにも反してしまいます。 そのため、これは最後の選択肢となります。
また、pear インストーラについては、 あまり賢くしすぎるべきではないという結論に達しました。 つまり、複数のメジャーリリースがあるパッケージについて 古いほうのバージョンをインストールしようとしたときに 「新しいメジャーバージョンが存在する」という警告は表示するが、 それ以上 (訳注: 勝手に新しいバージョンをインストールすること) はしないということです。 しかし、そのパッケージのすべてのメジャーバージョンは、 ひとつの場所 (そのパッケージのホームページ) にならべて表示されます。 これは、旧メジャーリリース用のチュートリアルに対応するために特に重要となります (メジャーバージョン 1 用のチュートリアル xyz には、単純に 'pear install Foo' と書いてあります。もしこれでシステムが 'Foo2' をインストールしてしまったら、おそらくユーザは混乱するでしょう)。
したがって、新しいメジャーバージョンは、 上で述べた例外をのぞいてあらゆる意味で「新しいパッケージ」となります。 新しいパッケージの名前は、上で述べた規約のいずれかひとつに従うものとします。