Los paquetes se nombran así cuando existe (o hubo) una necesidad de facilitar la transición entre dos versiones principales de un paquete, y se espera que el tiempo necesario para hacerlo sea largo. Durante el período de transición, tanto las versiones nuevas como las antiguas se mantienen disponibles, con el entendimiento de que en algún momento futuro se suspenderán las versiones anteriores.
A veces, el período de transición ocurre durante la versión del sistema que está utilizando actualmente. Para algunos paquetes, ocurre con la frecuencia suficiente como para esperar ver versiones de paquetes de transición en cada nueva versión del sistema. Las herramientas de desarrollo de software a menudo entran en esta categoría, ya que la actualización a nuevas herramientas en el mismo horario que las versiones del sistema puede no ser práctica. La dependencia de mi compañía de versiones particulares de GCC, Autoconf y Perl podría estar en un ciclo de 5 años, mientras que mi sistema operativo podría estar en un ciclo de actualización de 3 años. Por lo tanto, me resulta más fácil adoptar nuevos sistemas operativos si incluye mis versiones anteriores de algunos paquetes además de lo que estaba vigente en el momento en que se desarrolló el nuevo sistema operativo.
Otras veces, estos cambios importantes en la versión ocurrieron hace mucho tiempo, en el pasado, y ahora todos están en la versión actual. Este es el caso de Apache, por ejemplo. El cambio de 1.3 a 2.0 fue mucho mayor desde el punto de vista de la compatibilidad que cualquiera de los cambios de versión 2.x, por lo que una vez que todos estuvieron fuera de 1.3, ya no era necesario seguir ofreciendo múltiples versiones de Apache dentro de un lanzamiento de sistema operativo dado. Pero, una vez que tienes a todos usando el apache2paquete, no hay un buen argumento para renombrarlo como justo apache. Eso causaría una molestia de actualización innecesaria. Además, cuando hubo una necesidad percibida en el pasado de proporcionar dos versiones paralelas temporalmente, la necesidad probablemente se repetirá en el futuro.
Esta práctica de denominación de paquetes generalmente ocurre solo con bibliotecas o paquetes principales importantes. Para más paquetes periféricos, se espera que simplemente actualice a lo que sea actual en este momento.
Las bibliotecas se tratan más comúnmente de esta manera que las aplicaciones porque, por su naturaleza, otros paquetes dependen de ellas. Cuanto más popular es una biblioteca, más poco práctico es exigir que todos los demás paquetes, dependiendo de ella, se reconstruyan y se vuelvan a vincular únicamente para que la biblioteca pueda actualizarse paso a paso a una nueva versión principal sin este período de transición.
A menudo, cuando una aplicación se trata de esta manera, es porque contiene un elemento de biblioteca. Por ejemplo, Apache no es solo un servidor web, también proporciona una API de desarrollo para los complementos. ( mod_fooy tal.) Si alguien tiene un antiguo mod_somethingenlace contra el complemento ABI de Apache 1.3 y no lo ha actualizado para usar la nueva API 2.0, es conveniente si su sistema operativo continúa ofreciendo el antiguo Apache 1.3 hasta que todos los creadores del complemento tengan la oportunidad para actualizar sus complementos.