Les packages sont nommés de cette façon là où il est (ou était) nécessaire de faciliter la transition entre deux versions principales d'un package, et le temps nécessaire pour le faire devrait être long. Pendant la période de transition, les nouvelles et les anciennes versions sont maintenues disponibles, étant entendu qu'à un certain moment, les anciennes seront supprimées.
Parfois, la période de transition se produit pendant la version du système que vous utilisez actuellement. Pour certains packages, il arrive assez souvent que vous puissiez vous attendre à voir des versions de package de transition dans chaque nouvelle version du système. Les outils de développement logiciel entrent souvent dans cette catégorie, car la mise à niveau vers de nouveaux outils selon le même calendrier que les versions du système peut ne pas être pratique. La dépendance de mon entreprise à des versions particulières de GCC, Autoconf et Perl peut être sur un cycle de 5 ans, tandis que mon système d'exploitation peut être sur un cycle de mise à niveau de 3 ans. Il est donc plus facile pour moi d'adopter de nouveaux systèmes d'exploitation s'il inclut mes anciennes versions de certains packages en plus de ce qui était en cours au moment du développement du nouveau système d'exploitation.
D'autres fois, ces changements de version majeurs se sont produits il y a longtemps, dans le passé, et maintenant tout le monde est sur la version actuelle. C'est le cas d'Apache par exemple. Du point de vue de la compatibilité, le changement de 1.3 à 2.0 était beaucoup plus important que tous les changements de version 2.x.Par conséquent, une fois que tout le monde était hors de la version 1.3, il n'était plus nécessaire de continuer à proposer plusieurs versions d'Apache dans une version de système d'exploitation donnée. Mais, une fois que tout le monde utilise le apache2package, il n'y a pas de très bon argument pour le renommer simplement apache. Cela entraînerait un problème de mise à niveau inutile. En outre, là où il y avait un besoin perçu dans le passé de fournir temporairement deux versions parallèles, le besoin se reproduira probablement à l'avenir.
Cette pratique de dénomination des packages se produit généralement uniquement avec les bibliothèques ou les packages principaux importants. Pour les packages plus périphériques, vous devez simplement passer à ce qui est actuellement en cours.
Les bibliothèques sont plus couramment traitées de cette façon que les applications car, par leur nature, d'autres packages en dépendent. Plus une bibliothèque est populaire, plus il est impraticable d'exiger que tous les autres packages en fonction soient reconstruits et reliés à elle uniquement afin que la bibliothèque puisse être mise à niveau par étapes vers une nouvelle version majeure sans cette période de transition.
Souvent, lorsqu'une application est traitée de cette façon, c'est parce qu'elle contient un élément de bibliothèque. Par exemple, Apache n'est pas seulement un serveur Web, il fournit également une API de développement pour les plugins. ( mod_fooet autres). Si quelqu'un a un ancien mod_somethinglié au plugin Apache 1.3 ABI et ne l'a pas mis à niveau pour utiliser la nouvelle API 2.0, il est pratique si votre système d'exploitation continue d'offrir l'ancien Apache 1.3 jusqu'à ce que tous les créateurs de plugins aient une chance pour mettre à jour leurs plugins.