पैकेजों को इस तरह नामित किया जाता है जहां पैकेज के दो प्रमुख संस्करणों के बीच संक्रमण को कम करने की आवश्यकता होती है (या थी), और ऐसा करने के लिए आवश्यक समय लंबे होने की उम्मीद है। संक्रमण अवधि के दौरान, नए और पुराने दोनों संस्करणों को उपलब्ध कराया जाता है, इस समझ के साथ कि कुछ भविष्य के समय में पुराने को बंद कर दिया जाएगा।
कभी-कभी आपके द्वारा वर्तमान में उपयोग किए जा रहे सिस्टम रिलीज़ के दौरान संक्रमण अवधि होती है। कुछ पैकेजों के लिए, यह अक्सर पर्याप्त होता है कि आप हर नए सिस्टम रिलीज में संक्रमणकालीन पैकेज संस्करण देखने की उम्मीद कर सकते हैं । सॉफ़्टवेयर डेवलपमेंट टूल अक्सर इस श्रेणी में आते हैं, क्योंकि सिस्टम रिलीज़ होने के दौरान नए टूल में अपग्रेड करना व्यावहारिक नहीं हो सकता है। GCC, Autoconf और Perl के विशेष संस्करणों पर मेरी कंपनी की निर्भरता 5 वर्ष के चक्र पर हो सकती है, जबकि मेरा OS 3 वर्ष के उन्नयन चक्र पर हो सकता है। इसलिए मेरे लिए नए OS को अपनाना आसान हो जाता है अगर इसमें नए OS के विकसित होने के समय जो कुछ भी वर्तमान था उसके अलावा कुछ पैकेज के मेरे पुराने संस्करण भी शामिल हैं।
अन्य बार, ये प्रमुख संस्करण परिवर्तन बहुत पहले, अतीत में हुए थे, और अब हर कोई वर्तमान संस्करण पर है। उदाहरण के लिए यह अपाचे के साथ मामला है। 1.3 से 2.0 परिवर्तन किसी भी 2.x संस्करण परिवर्तन की तुलना में संगतता दृष्टिकोण से कहीं अधिक बड़ा सौदा था, इसलिए सभी के 1.3 से बंद हो जाने के बाद, किसी दिए गए OS रिलीज़ के भीतर कई Apache संस्करण प्रस्तुत करने की आवश्यकता नहीं रह गई थी। लेकिन, एक बार जब आप सभी को apache2पैकेज का उपयोग कर लेते हैं , तो इसे वापस नामांकित करने के लिए बहुत अच्छा तर्क नहीं है apache। यह एक अनावश्यक उन्नयन परेशानी का कारण होगा। इसके अलावा, जहां अस्थायी रूप से दो समानांतर संस्करण प्रदान करने के लिए अतीत में एक कथित आवश्यकता थी, भविष्य में शायद आवश्यकता पुन: प्राप्त होगी।
यह पैकेज नामकरण अभ्यास आमतौर पर केवल पुस्तकालयों या महत्वपूर्ण कोर पैकेजों के साथ होता है। अधिक परिधीय पैकेज के लिए, आपको इस समय जो भी चालू है, बस अपग्रेड करने की उम्मीद है।
पुस्तकालयों को आमतौर पर अनुप्रयोगों की तुलना में इस तरह से व्यवहार किया जाता है, क्योंकि उनकी प्रकृति से, अन्य पैकेज उन पर निर्भर करते हैं। एक पुस्तकालय जितना लोकप्रिय है, उतना ही अव्यावहारिक है कि यह मांग करना कि इसके आधार पर हर दूसरे पैकेज को फिर से बनाया जाए और पूरी तरह से इसके खिलाफ रिंकल किया जाए ताकि पुस्तकालय इस संक्रमण अवधि के बिना एक नए प्रमुख संस्करण में चरण-अपग्रेड हो सके।
अक्सर जब कोई एप्लिकेशन इस तरह से व्यवहार किया जा रहा होता है, तो इसका कारण यह है कि इसमें एक पुस्तकालय तत्व होता है। उदाहरण के लिए, अपाचे केवल एक वेब सर्वर नहीं है, यह प्लगइन्स के लिए एक विकास एपीआई भी प्रदान करता है। ( mod_fooऔर ऐसा।) यदि किसी के पास mod_somethingअपाचे 1.3 प्लगइन एबीआई के खिलाफ एक पुराना लिंक है और नए 2.0 एपीआई का उपयोग करने के लिए इसे उन्नत नहीं किया है, तो यह सुविधाजनक है यदि आपका ओएस पुराने अपाचे 1.3 की पेशकश जारी रखता है जब तक कि सभी प्लगइन रचनाकारों के पास एक मौका नहीं है। अपने प्लगइन्स को अद्यतन करने के लिए।