パッケージは、パッケージの2つのメジャーバージョン間の移行を容易にする必要がある(または必要だった)ような名前が付けられており、そのために必要な時間が長くなることが予想されます。移行期間中は、新しいバージョンと古いバージョンの両方が利用可能になり、将来のある時点で古いバージョンが廃止されることを理解しています。
現在使用しているシステムのリリース中に移行期間が発生する場合があります。一部のパッケージについては、頻繁に発生するため、新しいシステムリリースごとに移行パッケージのバージョンが表示されることを期待できます。システム開発と同じスケジュールで新しいツールにアップグレードすることは実用的ではない可能性があるため、ソフトウェア開発ツールは多くの場合このカテゴリに分類されます。私の会社は、GCC、Autoconf、Perlの特定のバージョンへの依存が5年サイクルであるのに対して、私のOSは3年のアップグレードサイクルである可能性があります。したがって、新しいOSが開発された時点で最新のものに加えて、一部のパッケージの古いバージョンが含まれている場合、新しいOSを採用しやすくなります。
また、これらのメジャーバージョンの変更は、はるか昔、過去に行われ、現在は誰もが現在のバージョンを使用しています。これは、たとえばApacheの場合です。1.3から2.0への変更は、互換性の観点から、2.xバージョンの変更よりもはるかに大きな問題であったため、1.3から外れると、特定のOSリリース内で複数のApacheバージョンを提供し続ける必要がなくなりました。ただし、一度apache2
パッケージを使用するようになったら、名前を単にに変更するのはあまり適切ではありませんapache
。それは不必要なアップグレードの面倒を引き起こすでしょう。また、過去に一時的に2つの並行バージョンを一時的に提供する必要性が認識されていた場合、将来的にはおそらくその必要性が再発するでしょう。
このパッケージ命名規則は、通常、ライブラリまたは重要なコアパッケージでのみ発生します。より多くの周辺機器パッケージについては、現時点で最新のものにアップグレードすることが期待されています。
ライブラリは、その性質上、他のパッケージがライブラリに依存しているため、アプリケーションよりもこの方法で一般的に扱われます。ライブラリの人気が高いほど、この移行期間なしにライブラリを新しいメジャーバージョンにステップアップグレードできるように、ライブラリに依存する他のすべてのパッケージを純粋に再構築および再リンクすることを要求するのは非現実的です。
多くの場合、アプリケーションがこのように扱われるのは、ライブラリ要素が含まれているためです。たとえば、Apacheは単なるWebサーバーではなく、プラグインの開発APIも提供します。(mod_foo
など)mod_something
Apache 1.3プラグインABIに対してリンクされた古いバージョンがあり、新しい2.0 APIを使用するようにアップグレードしていない場合、すべてのプラグイン作成者がチャンスを得るまでOSが古いApache 1.3を提供し続けると便利ですプラグインを更新します。