Pakiety są nazywane w ten sposób, w których istnieje (lub była) potrzeba ułatwienia przejścia między dwiema głównymi wersjami pakietu, a czas potrzebny na to jest długi. W okresie przejściowym dostępne są zarówno nowe, jak i stare wersje, przy założeniu, że w przyszłości zostaną wycofane starsze wersje.
Czasami okres przejściowy ma miejsce podczas używanej wersji systemu. W przypadku niektórych pakietów zdarza się tak często, że można spodziewać się przejściowych wersji pakietów w każdej nowej wersji systemu. Narzędzia do tworzenia oprogramowania często należą do tej kategorii, ponieważ aktualizacja do nowych narzędzi według tego samego harmonogramu co wydania systemu może nie być praktyczna. Zależność mojej firmy od konkretnych wersji GCC, Autoconf i Perl może być w cyklu 5-letnim, podczas gdy mój system operacyjny może być w 3-letnim cyklu aktualizacji. W związku z tym łatwiej jest mi adoptować nowe systemy operacyjne, jeśli zawierają one moje starsze wersje niektórych pakietów oprócz tego, co było aktualne w czasie tworzenia nowego systemu operacyjnego.
Innym razem te główne zmiany wersji miały miejsce dawno temu, a teraz wszyscy korzystają z bieżącej wersji. Tak jest na przykład w przypadku Apache. Zmiana z wersji 1.3 na 2.0 była znacznie większa z punktu widzenia kompatybilności niż jakakolwiek zmiana wersji 2.x, więc kiedy wszyscy wyłączyli wersję 1.3, nie było już potrzeby oferowania wielu wersji Apache w ramach danej wersji systemu operacyjnego. Ale kiedy już wszyscy będą korzystać z apache2pakietu, nie ma zbyt dobrego argumentu za przemianowaniem go z powrotem na just apache. Spowodowałoby to niepotrzebne problemy z aktualizacją. Poza tym tam, gdzie w przeszłości istniała odczuwalna potrzeba tymczasowego zapewnienia dwóch równoległych wersji, potrzeba ta prawdopodobnie powtórzy się w przyszłości.
Ta praktyka nazywania pakietów zwykle ma miejsce tylko w przypadku bibliotek lub ważnych pakietów podstawowych. Aby uzyskać więcej peryferyjnych pakietów, należy po prostu zaktualizować do obecnej wersji.
Biblioteki są traktowane w ten sposób częściej niż aplikacje, ponieważ z natury zależą od nich inne pakiety. Im bardziej popularna jest biblioteka, tym bardziej niepraktyczne jest wymaganie, aby każdy inny pakiet zależny od niego był przebudowywany i ponownie łączony z nią wyłącznie w celu umożliwienia stopniowej aktualizacji biblioteki do nowej głównej wersji bez tego okresu przejściowego.
Często, gdy aplikacja jest traktowana w ten sposób, dzieje się tak, ponieważ zawiera element biblioteki. Na przykład Apache to nie tylko serwer WWW, ale także zapewnia programistyczny interfejs API dla wtyczek. ( mod_fooi takie.) Jeśli ktoś ma stary mod_somethinglink do ABI wtyczki Apache 1.3 i nie uaktualnił go do używania nowszego API 2.0, wygodnie jest, jeśli Twój system operacyjny nadal oferuje stary Apache 1.3, dopóki wszyscy twórcy wtyczek nie będą mieli szansy zaktualizować swoje wtyczki.