I pacchetti sono denominati in modo tale che esiste (o era) la necessità di facilitare la transizione tra due versioni principali di un pacchetto e il tempo necessario per farlo dovrebbe essere lungo. Durante il periodo di transizione, vengono mantenute disponibili sia le versioni nuove che quelle precedenti, con la consapevolezza che in un secondo momento le versioni precedenti verranno interrotte.
A volte il periodo di transizione si verifica durante la versione del sistema che si sta attualmente utilizzando. Per alcuni pacchetti, accade abbastanza spesso che ci si può aspettare di vedere le versioni dei pacchetti di transizione in ogni nuova versione del sistema. Gli strumenti di sviluppo software spesso rientrano in questa categoria, poiché l'aggiornamento a nuovi strumenti nella stessa pianificazione delle versioni del sistema potrebbe non essere pratico. La dipendenza della mia azienda da particolari versioni di GCC, Autoconf e Perl potrebbe essere su un ciclo di 5 anni, mentre il mio sistema operativo potrebbe essere su un ciclo di aggiornamento di 3 anni. Pertanto, mi rende più semplice l'adozione di nuovi sistemi operativi se include le mie versioni precedenti di alcuni pacchetti oltre a ciò che era corrente al momento dello sviluppo del nuovo sistema operativo.
Altre volte, questi importanti cambiamenti di versione sono avvenuti molto tempo fa, in passato, e ora tutti sono nella versione attuale. Questo è il caso di Apache, per esempio. La modifica dalla 1.3 alla 2.0 era un affare molto più grande dal punto di vista della compatibilità rispetto a qualsiasi delle modifiche alla versione 2.x, quindi una volta che tutti erano fuori 1.3, non era più necessario continuare a offrire più versioni di Apache all'interno di una data versione del sistema operativo. Ma una volta che tutti hanno usato il apache2pacchetto, non c'è un buon argomento per rinominarlo in giusto apache. Ciò causerebbe una seccatura di aggiornamento non necessaria. Inoltre, laddove in passato si percepiva la necessità di fornire temporaneamente due versioni parallele, la necessità si ripresenterà probabilmente in futuro.
Questa pratica di denominazione dei pacchetti si verifica in genere solo con librerie o pacchetti core importanti. Per ulteriori pacchetti periferici, ci si aspetta che esegua l'upgrade a qualsiasi cosa sia attualmente disponibile.
Le librerie sono più comunemente trattate in questo modo rispetto alle applicazioni perché, per loro natura, altri pacchetti dipendono da esse. Più una libreria è popolare, più non è pratico richiedere che ogni altro pacchetto a seconda di essa venga ricostruito e ricollegato contro di essa puramente in modo che la libreria possa essere aggiornata a una nuova versione principale senza questo periodo di transizione.
Spesso quando un'applicazione viene trattata in questo modo, è perché contiene un elemento libreria. Ad esempio, Apache non è solo un server Web, ma fornisce anche un'API di sviluppo per i plugin. ( mod_fooe simili.) Se qualcuno ha un vecchio mod_somethinglinkato rispetto all'ABI del plug-in Apache 1.3 e non lo ha aggiornato per utilizzare l'API 2.0 più recente, è conveniente se il tuo sistema operativo continua a offrire il vecchio Apache 1.3 fino a quando tutti i creatori di plug-in non hanno una possibilità per aggiornare i loro plugin.