Os pacotes são nomeados assim onde existe (ou houve) a necessidade de facilitar a transição entre duas versões principais de um pacote, e o tempo necessário para fazê-lo deve ser longo. Durante o período de transição, as versões nova e antiga são mantidas disponíveis, com o entendimento de que, em algum momento futuro, as versões mais antigas serão descontinuadas.
Às vezes, o período de transição está acontecendo durante a versão do sistema que você está usando no momento. Para alguns pacotes, isso acontece com bastante frequência, e você pode esperar ver versões de pacotes de transição em cada nova versão do sistema. As ferramentas de desenvolvimento de software geralmente se enquadram nessa categoria, pois a atualização para novas ferramentas no mesmo horário das versões do sistema pode não ser prática. A dependência da minha empresa em versões específicas do GCC, Autoconf e Perl pode estar em um ciclo de 5 anos, enquanto meu sistema operacional pode estar em um ciclo de atualização de 3 anos. Portanto, facilita a adoção de novos sistemas operacionais se incluir minhas versões mais antigas de alguns pacotes, além do que estava atual no momento em que o novo sistema operacional estava sendo desenvolvido.
Outras vezes, essas grandes mudanças de versão ocorreram há muito tempo, no passado, e agora todos estão na versão atual. Este é o caso do Apache, por exemplo. Do ponto de vista da compatibilidade, a mudança de 1,3 para 2,0 foi muito maior do que qualquer outra versão da versão 2.x. Assim, quando todos saíram da versão 1.3, não havia mais necessidade de continuar oferecendo várias versões do Apache em uma determinada versão do sistema operacional. Porém, depois que todos usarem o apache2pacote, não haverá um argumento muito bom para renomeá-lo novamente apache. Isso causaria um aborrecimento desnecessário na atualização. Além disso, onde havia uma necessidade percebida no passado de fornecer duas versões paralelas temporariamente, a necessidade provavelmente se repetirá no futuro.
Essa prática de nomeação de pacotes geralmente acontece apenas com bibliotecas ou pacotes principais importantes. Para pacotes mais periféricos, é esperado que você apenas atualize para o que estiver atual no momento.
As bibliotecas são tratadas dessa maneira com mais frequência do que os aplicativos porque, por natureza, outros pacotes dependem delas. Quanto mais popular é uma biblioteca, mais impraticável é exigir que todos os outros pacotes dependentes sejam reconstruídos e vinculados novamente a ela puramente, para que a biblioteca possa ser atualizada passo a passo para uma nova versão principal sem esse período de transição.
Freqüentemente, quando um aplicativo está sendo tratado dessa maneira, é porque ele contém um elemento da biblioteca. Por exemplo, o Apache não é apenas um servidor da Web, ele também fornece uma API de desenvolvimento para os plugins. ( mod_fooe tal.) Se alguém tiver um antigo mod_somethingvinculado ao ABI do plug-in do Apache 1.3 e não o atualizou para usar a API 2.0 mais recente, é conveniente se o seu sistema operacional continuar oferecendo o antigo Apache 1.3 até que todos os criadores do plug-in tenham a chance para atualizar seus plugins.
