パッケージ名にバージョン番号が含まれるのはなぜですか？

パッケージの命名は、パッケージの2つのメジャーバージョン間の移行を簡素化する必要性に似ており、そうするのに必要な時間がかかることが予想されます。移行期間中は以前のバージョンと新しいバージョンの両方を使用できますが、今後の時点では以前のバージョンが廃止される予定です。

現在使用しているシステムバージョンの間に移行期間が発生することがあります。一部のパッケージでは、これが頻繁に発生し、次のコンバージョンパッケージのバージョンを見ることができます。すべて新しいシステムがリリースされました。ソフトウェア開発ツールは、システムリリースと同じスケジュールに基づいて新しいツールにアップグレードすることが実用的ではない可能性があるため、このカテゴリに属します。会社がGCC、Autoconf、およびPerlの特定のバージョンに依存する期間は5年サイクルですが、オペレーティングシステムは3年サイクルにアップグレードできます。したがって、新しいOSが開発されたときの最新バージョンに加えて、一部のパッケージの古いバージョンが含まれている場合は、新しいOSをより簡単に採用できます。

他の場合には、これらのメジャーバージョンの変更はずっと前に行われており、現在誰もが現在のバージョンを使用しています。たとえば、Apacheの場合です。互換性の観点からは、1.3から2.0への変更は2. Apacheバージョンよりはるかに大きいです。ただし、誰もがapache2パッケージを使用した後に名前を変更する理由はありませんapache。これにより、不要なアップグレードの問題が発生します。さらに、過去に一時的に2つの並列バージョンを提供する必要性が必要であると判断された場合、将来のニーズが発生する可能性があります。

このパッケージの命名慣行は、通常、ライブラリまたは重要なコアパッケージでのみ発生します。より多くのペリフェラルパッケージが必要な場合は、現在持っているパッケージに簡単にアップグレードできます。

ライブラリは本質的に他のパッケージがそれに依存しているため、アプリケーションよりもこの方法で処理されることがよくあります。ライブラリの人気が高まるにつれて、この移行期間なしでライブラリを新しいメジャーバージョンに徐々にアップグレードできるように、ライブラリに依存する他のすべてのパッケージを再構築して再リンクする必要があることは実用性が低くなります。

通常、アプリケーションがこのように処理される理由は、アプリケーションにライブラリ要素が含まれているためです。たとえば、Apacheは単なるWebサーバー以上であり、プラグイン用の開発APIも提供します。 （mod_fooちょっと待ってください。）誰かがmod_somethingApache 1.3プラグインABIへの古いリンクを持っていて、最新の2.0 APIを使用するようにアップグレードされていない場合は、すべてのプラグイン作成者がその可能性があるまでOSが古いApache 1.3を提供し続ける場合は、次のようになります。 。プラグインを更新するのに便利です。