डिपेंडेंसी वर्शन अपग्रेड करें

डिपेंडेंसी को अपग्रेड करने से, आपको उनकी नई सुविधाओं, गड़बड़ियों को ठीक करने के तरीकों, और सुधारों का ऐक्सेस मिलता है. अपनी डिपेंडेंसी को अपग्रेड करने के लिए, आपको यह समझना होगा कि Gradle, आपके अनुरोध किए गए वर्शन को कैसे हल करता है. साथ ही, आपको यह भी समझना होगा कि इससे क्या जोखिम हो सकते हैं और उन जोखिमों को कम करने के लिए क्या किया जा सकता है.

अपग्रेड करने की रणनीति तय करना

किसी भी अपग्रेड के लिए, जोखिम का विश्लेषण करना सबसे अहम चरण है. यह तय करें कि आपको हर डिपेंडेंसी को अपग्रेड करना है या नहीं. अपग्रेड की रणनीति तय करते समय, कई बातों का ध्यान रखना ज़रूरी है. इनमें ये भी शामिल हैं:

लाइब्रेरी बनाना

क्या आपका ऐप्लिकेशन ऐसा है जिसे उपयोगकर्ता डाउनलोड करके किसी डिवाइस पर चलाते हैं? क्या आपने कोई लाइब्रेरी बनाई है, ताकि अन्य डेवलपर अपने ऐप्लिकेशन बना सकें?

अगर कोई ऐप्लिकेशन बनाया जा रहा है, तो आपका ध्यान उसे अप-टू-डेट और स्थिर रखने पर होना चाहिए.

अगर कोई लाइब्रेरी बनाई जा रही है, तो आपका ध्यान दूसरे डेवलपर के ऐप्लिकेशन पर होना चाहिए. आपके अपग्रेड से आपके उपभोक्ताओं पर असर पड़ता है. अगर आपने अपनी किसी डिपेंडेंसी को अपग्रेड किया है, तो वह वर्शन Gradle की डिपेंडेंसी रिज़ॉल्यूशन की प्रक्रिया के लिए एक उम्मीदवार बन जाता है. इससे, हो सकता है कि ऐप्लिकेशन उस डिपेंडेंसी का इस्तेमाल न कर पाए.

पहला - जहां भी हो सके वहां अपनी लाइब्रेरी की डिपेंडेंसी कम करें. आपके पास जितनी कम डिपेंडेंसी होंगी, आपके उपभोक्ता के डिपेंडेंसी रिज़ॉल्यूशन पर उतना ही कम असर पड़ेगा.

सेमेंटिक वर्शनिंग का इस्तेमाल करना न भूलें, ताकि यह पता चल सके कि आपने किस तरह के बदलाव किए हैं. उदाहरण के लिए, AndroidX, सेमेटिक वर्शनिंग का इस्तेमाल करता है और रिलीज़ से पहले वर्शनिंग स्कीम जोड़ता है. अपने उपभोक्ताओं को परेशानी से बचाने के लिए, major वर्शन पर अपग्रेड करने से बचें.

उपयोगकर्ताओं को रिलीज़ से पहले टेस्ट करने के लिए, अपनी लाइब्रेरी का रिलीज़-कैंडिडेट (आरसी) बनाएं.

अपनी लाइब्रेरी के ऐप्लिकेशन बाइनरी इंटरफ़ेस (एबीआई) को काम करते रहने के बारे में जानने के लिए, लाइब्रेरी बनाने वालों के लिए, पुराने सिस्टम के साथ काम करने से जुड़े दिशा-निर्देश देखें. इंटिग्रेशन टेस्ट और बाइनरी के साथ काम करने की पुष्टि करने वाले टूल का इस्तेमाल करके, पक्का करें कि एबीआई में किए गए बदलाव, आपके वर्शन में किए गए बदलाव से मेल खाते हों.

अगर आपने लाइब्रेरी के पुराने वर्शन में patch में सुधार किए हैं, तो आपके उपयोगकर्ताओं को लाइब्रेरी को अगले major या minor वर्शन में अपग्रेड करने की ज़रूरत नहीं है. ऐसा तब तक नहीं करना होगा, जब तक उन्हें नई सुविधाएं नहीं चाहिए. इन अपग्रेड में, ट्रांज़िशन डिपेंडेंसी को अपग्रेड करने से बचें.

अगर लाइब्रेरी को अपग्रेड करने के लिए, ऐसे बदलाव करने ज़रूरी हैं जो आपके उपयोगकर्ताओं के लिए खास तौर पर मुश्किल हो सकते हैं, तो उन्हें नए आर्टफ़ैक्ट के तौर पर रिलीज़ करें. इससे पुराने और नए वर्शन एक साथ काम कर पाएंगे और धीरे-धीरे रोल आउट किए जा सकेंगे.

ध्यान दें: अगर आपकी किसी डिपेंडेंसी के अपग्रेड में एपीआई में कोई बड़ा बदलाव होता है, तो हो सकता है कि आप उसे major या minor रिलीज़ में अपग्रेड करना चाहें. साथ ही, ज़रूरी बदलाव भी करें. ऐसा न करने पर, आपकी लाइब्रेरी के उपयोगकर्ता ऐसा कर सकते हैं. इससे आपकी लाइब्रेरी और उस डिपेंडेंसी के बीच काम करने में समस्याएं आ सकती हैं. ऐसा तब भी हो सकता है, जब आपकी लाइब्रेरी में कोई बदलाव न हुआ हो. सिर्फ़ उस डिपेंडेंसी को अपग्रेड करने के लिए, नया वर्शन रिलीज़ किया जा सकता है.

रिलीज़ साइकल

आपका ऐप्लिकेशन या लाइब्रेरी कितनी बार रिलीज़ होती है?

डेवलपमेंट और रिलीज़ साइकल कम होना

  • अपग्रेड करने के लिए कम समय है.
  • आपके पास समय कम हो सकता है.
  • बार-बार छोटे अपग्रेड करने से, काम का बोझ कम हो सकता है.
  • अगर लाइब्रेरी को अपग्रेड करने में समस्या आती है, तो उस अपग्रेड को तुरंत रोल-बैक किया जा सकता है.
  • अगर आपने ऐसे प्लग इन या टूल का इस्तेमाल किया है जो डिपेंडेंसी अपग्रेड को अपने-आप करने में मदद करते हैं, तो नतीजों का विश्लेषण करके, जोखिम की जांच करना न भूलें.

डेवलपमेंट और रिलीज़ साइकल ज़्यादा लंबे होते हैं

  • अपग्रेड करने और उनकी जांच करने के लिए ज़्यादा समय है.
  • आपके साइकल के दौरान, डिपेंडेंसी के नए वर्शन रिलीज़ होने की संभावना ज़्यादा होती है.
  • अपग्रेड को वापस रोल करने और अपने ऐप्लिकेशन या लाइब्रेरी को रिलीज़ करने में ज़्यादा समय लगता है.

नई सुविधाओं के बारे में अप-टू-डेट रहें

क्या आपको उपलब्ध नई सुविधाओं और एपीआई का इस्तेमाल करना पसंद है या सिर्फ़ तब अपग्रेड करना है, जब आपको कोई सुविधा या गड़बड़ी ठीक करनी हो?

बार-बार अपग्रेड करने के फ़ायदे और नुकसान के बारे में सोचें. आने वाले समय में अपग्रेड करना आसान होता है (इंटिग्रेट करने के लिए कम बदलाव करने होते हैं), लेकिन अपग्रेड करने के जोखिम भी ज़्यादा होते हैं.

लाइब्रेरी के रिलीज़ से पहले वाले वर्शन (अल्फ़ा, बीटा, रिलीज़ कैंडिडेट) में अपग्रेड की जांच करने से, स्टेबल रिलीज़ उपलब्ध होने पर, उन्हें तैयार करने में मदद मिल सकती है.

नई डिपेंडेंसी

अगर कोई नई डिपेंडेंसी जोड़ी जा रही है, तो समीक्षा की ऐसी प्रोसेस अपनाएं जो उस लाइब्रेरी की सभी जोखिम वाली शर्तों की जांच करे. इससे यह पक्का किया जा सकेगा कि उसका सही तरीके से आकलन किया गया है. समीक्षा किए बिना नई डिपेंडेंसी जोड़ने की अनुमति न दें.

खास टीम

क्या आपके पास खास तौर पर बिल्ड करने के लिए कोई टीम है? क्या आपके सॉफ़्टवेयर इंजीनियर, बिल्ड को मैनेज करते हैं? अपग्रेड से जुड़े जोखिमों का विश्लेषण करने और नए वर्शन की जांच करने में, खास तौर पर बनाई गई टीम ज़्यादा समय बिता सकती है. इससे यह पक्का किया जा सकता है कि इंजीनियर नए वर्शन का इस्तेमाल करने से पहले, बिल्ड सही तरीके से काम कर रहा है.

अपग्रेड का टाइप

कुछ अपग्रेड दूसरों की तुलना में ज़्यादा ज़रूरी होते हैं. देखें कि आपके लिए कौनसे सबसे ज़रूरी हैं.

आम तौर पर, Gradle और Gradle प्लग इन जैसे बिल्ड टूल के अपग्रेड से आपके उपयोगकर्ताओं पर कम असर पड़ता है. साथ ही, ज़्यादातर जोखिम आपके बिल्ड में ही होता है. इन बदलावों की पुष्टि करने में, बिल्ड की मदद मिलती है. लाइब्रेरी और SDK टूल के अपग्रेड की पुष्टि करना ज़्यादा मुश्किल होता है. साथ ही, इनसे आपके उपयोगकर्ताओं को ज़्यादा खतरा होता है.

Android Gradle प्लग इन (AGP) — यह टूल, आपके Android ऐप्लिकेशन या लाइब्रेरी को बनाने के लिए इस्तेमाल किया जाता है. यह सबसे ज़रूरी अपग्रेड है, क्योंकि इसमें अक्सर परफ़ॉर्मेंस में सुधार, गड़बड़ियों को ठीक करने, नए लिंट नियम, और Android प्लैटफ़ॉर्म के नए वर्शन के लिए सहायता शामिल होती है या उन्हें चालू किया जाता है.

Gradle — AGP या किसी दूसरे Gradle प्लग इन को अपग्रेड करने पर, आपको अक्सर Gradle को भी अपग्रेड करना पड़ता है.

अन्य Gradle प्लग इन — कभी-कभी Gradle के प्लग इन एपीआई में बदलाव होता है. Gradle को अपग्रेड करते समय, इस्तेमाल किए जा रहे प्लग इन के अपग्रेड देखें.

Kotlin और Java — कुछ लाइब्रेरी और प्लग इन के लिए, Kotlin या Java के कम से कम वर्शन की ज़रूरत होती है. इसके अलावा, भाषा की नई सुविधाओं, एपीआई या परफ़ॉर्मेंस में हुए सुधारों का फ़ायदा पाने के लिए भी ऐसा किया जा सकता है.

Android प्लैटफ़ॉर्म — Play Store के लिए, Android SDK टूल को नियमित तौर पर अपग्रेड करना ज़रूरी है. आपको Android SDK टूल के नए वर्शन की जांच जल्द से जल्द करनी चाहिए. SDK टूल के कुछ अपग्रेड के लिए, आपके ऐप्लिकेशन में बदलाव करने की ज़रूरत होती है. जैसे, नई अनुमतियां या नए एपीआई का इस्तेमाल करना.

लाइब्रेरी — क्या आपको लाइब्रेरी को प्राथमिकता देनी है, ताकि वे आपके पूरे आर्किटेक्चर के हिसाब से काम कर सकें?

  • प्लैटफ़ॉर्म और आर्किटेक्चर से जुड़ी लाइब्रेरी, जैसे कि AndroidX, अक्सर नई सुविधाओं का फ़ायदा पाने या प्लैटफ़ॉर्म में बदलाव करने के लिए बदलती रहती हैं. Android प्लैटफ़ॉर्म या आर्किटेक्चर से जुड़ी अन्य लाइब्रेरी को अपग्रेड करते समय, इन लाइब्रेरी को भी अपग्रेड करें.
  • लाइब्रेरी के अन्य अपग्रेड को तब तक रोका या टाला जा सकता है, जब तक आपको कोई नई सुविधा या गड़बड़ी ठीक करने की ज़रूरत न हो.

Android Studio — Android Studio को अप-टू-डेट रखने से, आपको IntelliJ IDEA प्लैटफ़ॉर्म की नई सुविधाओं और गड़बड़ियों को ठीक करने के टूल का ऐक्सेस मिलता है. साथ ही, आपको Android के नए SDK टूल के साथ काम करने की सुविधा भी मिलती है.

उपलब्ध टूल

अगर आपने ऐसे प्लग इन या टूल का इस्तेमाल किया है जो डिपेंडेंसी अपग्रेड को अपने-आप करने में मदद करते हैं, तो नतीजों का विश्लेषण करके, जोखिम की जांच करना न भूलें.

खास तरह के अपग्रेड के लिए रणनीतियां

कुछ तरह की डिपेंडेंसी को अपग्रेड करने से, कैस्केडिंग इफ़ेक्ट पड़ सकता है. इस वजह से, अन्य तरह की डिपेंडेंसी को भी अपग्रेड करना पड़ सकता है. हम टूल और लाइब्रेरी के बीच की इंटरडिपेंडेंसी में, बिल्ड एलिमेंट के बीच के संबंधों के बारे में बात करते हैं.

डिपेंडेंसी और उनके रिलेशनशिप बनाना
पहली इमेज. संबंध बनाएं.

हर तरह के कॉम्पोनेंट को अपग्रेड करते समय, इस बात का ध्यान रखें कि अपग्रेड से बिल्ड में मौजूद अन्य कॉम्पोनेंट पर क्या असर पड़ेगा.

Android Gradle प्लग इन (AGP)

Android Studio में AGP अपग्रेड असिस्टेंट शामिल है, जो इन टास्क में मदद कर सकता है.

अगर आपने Assistant का इस्तेमाल किया है या मैन्युअल तरीके से अपग्रेड किया है, तो इन बातों का ध्यान रखें:

AGP के रिलीज़ नोट देखें.

Gradle को कम से कम सूची में दिए गए वर्शन पर अपग्रेड करें.

Android Studio को ऐसे वर्शन पर अपग्रेड करें जो चुने गए AGP वर्शन के साथ काम करता हो.

Android Studio और AGP के उन वर्शन का इस्तेमाल करें जो उस Android SDK टूल के साथ काम करते हैं जिसका आपको इस्तेमाल करना है.

SDK Build Tools, NDK, और JDK के साथ काम करने की जांच करें.

अगर आपने संगठन के अंदर या सार्वजनिक तौर पर इस्तेमाल करने के लिए, ऐसा Gradle प्लग इन डेवलप किया है जो AGP के डेटा को बढ़ाता है या उसका इस्तेमाल करता है, तो देखें कि आपको अपना प्लग इन अपग्रेड करना होगा या नहीं. कभी-कभी AGP, एपीआई को बंद कर देता है और बाद में हटा देता है. इससे, पिछले प्लग इन के साथ काम करने में समस्याएं आती हैं.

Kotlin कंपाइलर, भाषा, और रनटाइम

पहले से मौजूद समस्याओं और काम न करने से जुड़ी समस्याओं के बारे में जानने के लिए, Kotlin रिलीज़ नोट देखें.

अगर Jetpack Compose का इस्तेमाल किया जाता है, तो:

अगर Kotlin सिंबल प्रोसेसिंग (KSP) का इस्तेमाल किया जाता है, तो सेटअप के लिए KSP क्विकस्टार्ट और उपलब्ध वर्शन के लिए KSP रिलीज़ देखें. ध्यान दें कि आपको KSP के उस वर्शन का इस्तेमाल करना होगा जो Kotlin के वर्शन से मेल खाता हो. उदाहरण के लिए, अगर Kotlin 2.0.21 का इस्तेमाल किया जा रहा है, तो KSP प्लग इन के 2.0.21 से शुरू होने वाले किसी भी वर्शन का इस्तेमाल किया जा सकता है. जैसे, 2.0.21-1.0.25. आम तौर पर, आपको KSP प्रोसेसर (जैसे, Room कंपाइलर, जो आपकी बिल्ड फ़ाइलों में ksp डिपेंडेंसी के तौर पर दिखता है) को अपग्रेड करने की ज़रूरत नहीं होती. KSP प्लग इन, कंपाइलर एपीआई के ज़्यादातर हिस्से को अलग करता है. साथ ही, प्रोसेसर के लिए इस्तेमाल किया जाने वाला KSP एपीआई स्थिर होता है.

इस्तेमाल किए जा रहे सभी अन्य Kotlin कंपाइलर प्लग इन को अपग्रेड करें. Kotlin Compiler Plugin API, रिलीज़ के बीच अक्सर बदलता रहता है. साथ ही, प्लग इन के लिए काम करने वाले एपीआई का इस्तेमाल करना ज़रूरी है. अगर प्लग इन, कंपाइलर प्लग इन में शामिल है, तो आपको Kotlin कंपाइलर के उसी वर्शन का इस्तेमाल करना होगा. किसी भी अन्य कंपाइल प्लग इन के लिए, सही मैपिंग के लिए उनके दस्तावेज़ देखें.

ध्यान दें कि जिन कंपाइलर प्लगिन को Kotlin कंपाइलर के साथ मैनेज नहीं किया जाता है उन्हें रिलीज़ होने में अक्सर देरी होती है. ऐसा इसलिए होता है, क्योंकि वे कंपाइलर प्लगिन एपीआई के स्थिर होने का इंतज़ार करते हैं. Kotlin को अपग्रेड करने से पहले, देख लें कि आपके इस्तेमाल किए जा रहे सभी कंपाइलर प्लग इन के लिए, मिलते-जुलते अपग्रेड उपलब्ध हों.

आखिर में, कुछ मामलों में Kotlin भाषा में बदलाव होता है. ऐसे में, आपको अपना कोड अपडेट करना पड़ता है. ऐसा अक्सर तब होता है, जब प्रयोग के तौर पर उपलब्ध सुविधाओं को आज़माया जा रहा हो. अगर Kotlin कंपाइलर को अपग्रेड करने के बाद, आपका कोड सही तरीके से बिल्ड नहीं होता है, तो Kotlin रिलीज़ नोट में भाषा में हुए बदलावों या रनटाइम लाइब्रेरी के काम न करने की जानकारी देखें.

Kotlin कंपाइलर प्लग इन

अगर आपको Kotlin कंपाइलर प्लग इन को अपग्रेड करना है, तो Kotlin के इस्तेमाल किए जा रहे वर्शन के हिसाब से अपग्रेड करें.

ज़्यादातर Kotlin कंपाइलर प्लग इन, Kotlin कंपाइलर के उसी वर्शन का इस्तेमाल करते हैं या Kotlin कंपाइलर के ज़रूरी वर्शन के साथ शुरू होते हैं. उदाहरण के लिए, अगर प्लग इन का वर्शन 2.0.21-1.0.25 है, तो आपको Kotlin कंपाइलर के 2.0.21 वर्शन का इस्तेमाल करना होगा.

Kotlin कंपाइलर के वर्शन को बदलने के लिए, कभी-कभी अन्य बदलाव करने पड़ते हैं.

लाइब्रेरी

लाइब्रेरी, आपके बिल्ड में सबसे ज़्यादा अपग्रेड की जाने वाली डिपेंडेंसी होती हैं. आपको Android Studio एडिटर में, उपलब्ध अपग्रेड दिखेंगे.

कुछ लाइब्रेरी में, लाइब्रेरी का इस्तेमाल करने के लिए कम से कम compileSdk या minSdk की ज़रूरत होती है. अगर आपने कम से कम बताए गए compileSdk का इस्तेमाल नहीं किया है, तो आपके बिल्ड पूरा नहीं होंगे. हालांकि, आपके ऐप्लिकेशन का minSdk अपने-आप, लाइब्रेरी डिपेंडेंसी और बिल्ड फ़ाइलों में बताई गई सभी minSdk वैल्यू में से सबसे ज़्यादा वैल्यू पर सेट हो जाता है.

कुछ लाइब्रेरी, इस्तेमाल के लिए Kotlin के कम से कम वर्शन की जानकारी भी देती हैं. अपनी बिल्ड फ़ाइलों में Kotlin के वर्शन को अपडेट करें, ताकि वह कम से कम तय किए गए वर्शन के बराबर हो.

Gradle

कभी-कभी Gradle के नए वर्शन, मौजूदा एपीआई को बंद कर देते हैं. साथ ही, आने वाले समय में रिलीज़ होने वाले वर्शन से उन एपीआई को हटा देते हैं. अगर आपने Gradle प्लगिन डेवलप किया है, तो अपने प्लगिन को जल्द से जल्द अपग्रेड करें. खास तौर पर, अगर वह प्लगिन सार्वजनिक है.

Gradle के कुछ अपग्रेड के लिए, इस्तेमाल किए जा रहे प्लग इन के नए वर्शन ढूंढने की ज़रूरत होती है. ध्यान दें कि ये प्लग इन, डेवलपमेंट में थोड़ा समय ले सकते हैं. ऐसा इसलिए, क्योंकि ये प्लग इन, Gradle प्लग इन के नए एपीआई के साथ काम करने के लिए, प्लग इन को अपग्रेड करते हैं.

Gradle को अपग्रेड करने के लिए:

Gradle प्लग इन

अपग्रेड किए गए Gradle प्लग इन, कभी-कभी नए या बदले गए Gradle API का इस्तेमाल करते हैं. इसके लिए, Gradle को अपग्रेड करना पड़ता है या आपकी बिल्ड फ़ाइलों में उनके कॉन्फ़िगरेशन में बदलाव करना पड़ता है. दोनों ही मामलों में, आपको काम न करने की जानकारी देने के लिए, बिल्ड से जुड़ी चेतावनियां या गड़बड़ियां दिखेंगी.

प्लग इन अपग्रेड करते समय, Gradle को भी अपग्रेड करें.

Android SDK टूल

Android Studio में Android SDK टूल के लिए अपग्रेड असिस्टेंट की सुविधा मौजूद है. इससे इन कामों में मदद मिल सकती है.

अगर आपने Assistant का इस्तेमाल किया है या मैन्युअल तरीके से अपग्रेड किया है, तो इन बातों का ध्यान रखें:

Android SDK टूल के हर रिलीज़ में नई सुविधाएं और एपीआई शामिल होते हैं. साथ ही, गड़बड़ियों को ठीक किया जाता है और इसके काम करने के तरीके में बदलाव किए जाते हैं. Play Store के लिए, आपको targetSdk को अपडेट करना ज़रूरी है. हालांकि, targetSdk को समयसीमा खत्म होने से पहले अपडेट करें, ताकि ज़रूरी बदलाव करने के लिए आपको ज़्यादा समय मिल सके.

Android SDK टूल को अपग्रेड करने से पहले, रिलीज़ नोट को ध्यान से पढ़ें. 'उपयोगकर्ता के व्यवहार में हुए बदलाव' सेक्शन पर ध्यान दें. इसमें ये बदलाव शामिल हैं:

  • नई अनुमतियां, जिनका अनुरोध आपको इंस्टॉल या रनटाइम के दौरान करना होगा.
  • बंद किए गए एपीआई और उनके बदले इस्तेमाल किए जा सकने वाले एपीआई.
  • एपीआई या उनके काम करने के तरीके में होने वाले बदलाव.
  • नए Kotlin या Java एपीआई, जिनका असर आपके कोड पर पड़ सकता है.

'कार्रवाइयों में हुए बदलाव' सेक्शन काफ़ी लंबा हो सकता है. हालांकि, इस पर ध्यान दें, क्योंकि इसमें अक्सर ऐसे अहम बदलाव होते हैं जिन्हें आपको अपने ऐप्लिकेशन में करना होता है.

Play Store की ज़रूरी शर्तों को पूरा करने के लिए, आपको targetSdk को अपग्रेड करना होगा. compileSdk को अपग्रेड करना ज़रूरी नहीं है. हालांकि, ऐसा करने पर आपको नए एपीआई का ऐक्सेस मिलता है. ध्यान दें कि AndroidX जैसी कुछ लाइब्रेरी में, compileSdk की कम से कम ज़रूरत शामिल होती है.

डेवलपमेंट के दौरान SDK की नई सुविधाओं का फ़ायदा पाने और अपने ऐप्लिकेशन के बिल्ड के दौरान, ऐप्लिकेशन के साथ काम करने की सुविधा को पक्का करने के लिए, Android Gradle प्लग इन (AGP) और Android Studio को अपग्रेड करें. इनमें नए SDK टूल के लिए नए और बेहतर टूल शामिल हैं. Android एपीआई लेवल के लिए टूल के कम से कम वर्शन देखें.

Android SDK टूल को अपग्रेड करते समय, इस्तेमाल की जा रही सभी AndroidX लाइब्रेरी को भी अपग्रेड करें. AndroidX, Android SDK टूल के सभी वर्शन के साथ बेहतर तरीके से काम करने और परफ़ॉर्मेंस को बेहतर बनाने के लिए, अक्सर नए और अपडेट किए गए एपीआई का इस्तेमाल करता है.

Android Studio

आम तौर पर, Android Studio को किसी भी समय अपग्रेड किया जा सकता है. आपको AGP टूल को अपग्रेड करने या Android SDK टूल को अपग्रेड करने के लिए कहा जा सकता है. हमारा सुझाव है कि आप इन अपग्रेड को ज़रूर करें. हालांकि, ऐसा करना ज़रूरी नहीं है.

अगर आपको बाद में AGP या Android SDK टूल को अपग्रेड करने के लिए, Android Studio का इस्तेमाल करना है, तो आपको टूल मेन्यू में ये विकल्प मिलेंगे:

Java

अगर आपके Android ऐप्लिकेशन में Java सोर्स कोड है, तो हो सकता है कि आप नए Java API का फ़ायदा लेना चाहें.

Android SDK टूल का हर वर्शन, Java API के सबसेट और भाषा की सुविधाओं के साथ काम करता है. AGP, डिसगैरिंग नाम की प्रोसेस का इस्तेमाल करके, Android SDK टूल के पुराने वर्शन के साथ काम करने की सुविधा देता है.

Android SDK के रिलीज़ नोट में बताया जाता है कि कौनसा Java लेवल काम करता है और संभावित समस्याएं क्या हैं. इनमें से कुछ समस्याओं का असर Kotlin सोर्स कोड पर भी पड़ सकता है, क्योंकि Kotlin के पास उन ही Java API का ऐक्सेस होता है. रिलीज़ नोट के 'कार्रवाइयों में हुए बदलाव' सेक्शन में दिखने वाले JDK API सेक्शन पर ध्यान दें. भले ही, आपके पास कोई Java सोर्स कोड न हो.

JDK के इस्तेमाल के बारे में, आपकी बिल्ड स्क्रिप्ट में कई जगहों पर बताया गया है. ज़्यादा जानकारी के लिए, Android बिल्ड में Java के वर्शन देखें.

अपग्रेड का विश्लेषण

किसी डिपेंडेंसी को अपग्रेड करने पर, एपीआई और उसके काम करने के तरीके में बदलाव, इस्तेमाल से जुड़ी नई ज़रूरी शर्तें, सुरक्षा से जुड़ी नई समस्याएं या लाइसेंस में बदलाव जैसे जोखिम हो सकते हैं. उदाहरण के लिए, क्या आपको:

  • एपीआई में हुए बदलावों के लिए कोड बदलना?
  • क्या आपको अनुमति की नई जांच जोड़नी है?
  • क्या आपको व्यवहार में हुए बदलावों के लिए, अतिरिक्त टेस्ट बनाने हैं या मौजूदा टेस्ट में बदलाव करने हैं?

ध्यान रखें कि आपने जिस डिपेंडेंसी को अपग्रेड किया है उसने अपनी डिपेंडेंसी के वर्शन अपग्रेड कर दिए हैं. इससे, बदलावों का एक बड़ा सेट तेज़ी से स्पाइडर किया जा सकता है.

अगर आपने ऐसे प्लग इन या टूल का इस्तेमाल किया है जो डिपेंडेंसी अपग्रेड को अपने-आप करने में मदद करते हैं, तो ध्यान रखें कि ये आपके लिए कोई विश्लेषण नहीं करते. ये लाइब्रेरी के सबसे नए वर्शन पर अपग्रेड करते हैं. यह न मानें कि इस तरह के अपने-आप होने वाले अपग्रेड के बाद, सब कुछ ठीक से काम करेगा.

अपग्रेड का विश्लेषण करना, अपग्रेड को सफल बनाने की कुंजी है:

  1. अपग्रेड करने से पहले और बाद में, डिपेंडेंसी में हुए अंतर का पता लगाएं.
  2. हर बदलाव की जांच करें और उससे जुड़े जोखिमों का पता लगाएं.
  3. जोखिम कम करना या बदलावों को स्वीकार या अस्वीकार करना.

डिपेंडेंसी में अंतर का पता लगाना

अपग्रेड के विश्लेषण का पहला चरण यह तय करना है कि आपकी डिपेंडेंसी कैसे बदलती हैं. बदलावों को तुरंत देखने के लिए, वर्शन कंट्रोल (VCS, जैसे कि Git) और Dependency Guard प्लग इन का फ़ायदा लें. आपका लक्ष्य, पहले और बाद के स्नैपशॉट बनाना और उनकी तुलना करना है.

अपना पहला बेसलाइन सेट अप करना और बनाना

अपग्रेड शुरू करने से पहले, पक्का कर लें कि आपका प्रोजेक्ट सही तरीके से बिल्ड हो गया हो.

हमारा सुझाव है कि ज़्यादा से ज़्यादा चेतावनियों को ठीक करें या उन चेतावनियों को ट्रैक करने के लिए बेसलाइन बनाएं जो आपको पहले दिख चुकी हैं.

  • Lint

    • चेतावनियों को गड़बड़ियों के तौर पर दिखाने के लिए,
    android {
    // ...
    lint {
        warningsAsErrors = true
    }
}

    को हर मॉड्यूल में अपने build.gradle.kts से जोड़ें.

    • इसके अलावा, अगर आपको पहले से ही कई चेतावनियां मिल रही हैं, तो Android lint का बेसलाइन बनाएं. समय के साथ, मौजूदा चेतावनियों को हटाना न भूलें (या उन चेतावनियों को दबा दें जिनमें आपकी दिलचस्पी नहीं है)

  • Kotlin कंपाइलर: सभी चेतावनियों को गड़बड़ियों के तौर पर दिखाने के लिए, -Werror को चालू करें. विकल्प तय करने का तरीका देखें.

  • अन्य टूल: अगर आपने बेसलाइन ट्रैकिंग की सुविधा वाले अन्य स्टैटिक विश्लेषण टूल का इस्तेमाल किया है, तो उनके बेसलाइन सेट अप करें.

चेतावनी के बेसलाइन की मदद से, अपनी डिपेंडेंसी को अपग्रेड करने पर मिलने वाली नई चेतावनियां आसानी से देखी जा सकती हैं. Dependency Guard का इस्तेमाल करके, डिपेंडेंसी और उनके वर्शन में हुए बदलाव देखे जा सकते हैं.

अपने gradle/libs.versions.toml वर्शन कैटलॉग में, यह जोड़ें:

[versions]
dependencyGuard = "0.5.0"

[plugins]
dependency-guard = { id = "com.dropbox.dependency-guard", version.ref = "dependencyGuard" }

साथ ही, अपने ऐप्लिकेशन की बिल्ड फ़ाइल में यह कोड जोड़ें:

Kotlin

plugins {
    alias(libs.plugins.dependency.guard)
}

dependencyGuard {
    configuration("releaseRuntimeClasspath")
}

Groovy

plugins {
    alias(libs.plugins.dependency.guard)
}

dependencyGuard {
    configuration('releaseRuntimeClasspath')
}

releaseRuntimeClasspath कॉन्फ़िगरेशन, टारगेट होने की संभावना वाला कॉन्फ़िगरेशन है. हालांकि, अगर आपको किसी दूसरे कॉन्फ़िगरेशन का इस्तेमाल करना है, तो सभी उपलब्ध कॉन्फ़िगरेशन देखने के लिए, अपनी बिल्ड फ़ाइल में सूची में शामिल कॉन्फ़िगरेशन के बिना ./gradlew dependencyGuard चलाएं.

सेटअप करने के बाद, app/dependencies/releaseRuntimeClasspath.txt में रिपोर्ट जनरेट करने के लिए ./gradlew dependencyGuard चलाएं. यह आपकी बेसलाइन रिपोर्ट है. इसे सेव करने के लिए, अपने वर्शन कंट्रोल सिस्टम (वीसीएस) में कमिट करें.

ध्यान रखें कि डिपेंडेंसी गार्ड सिर्फ़ लाइब्रेरी डिपेंडेंसी की सूची कैप्चर करता है. आपकी बिल्ड फ़ाइलों में अन्य डिपेंडेंसी भी होती हैं, जैसे कि Android SDK टूल और JDK वर्शन. डिपेंडेंसी में बदलाव होने से पहले, अपने वीसीएस में बदलावों को कमिट करने पर, वीसीएस के डिफ़रेंस की सुविधा उन बदलावों को भी हाइलाइट कर सकती है.

अपग्रेड करना और अपने बेसलाइन से तुलना करना

बेसलाइन तैयार होने के बाद, डिपेंडेंसी और बिल्ड में किए गए उन बदलावों को अपग्रेड करें जिनकी आपको जांच करनी है. इस समय अपने सोर्स कोड या संसाधनों को अपग्रेड न करें.

नई लिंट चेतावनियां या गड़बड़ियां देखने के लिए, ./gradlew lint चलाएं. किसी भी अहम समस्या को ठीक करें. इसके बाद, ./gradlew lint -Dlint.baselines.continue=true को चलाकर चेतावनी का बेसलाइन अपडेट करें. अगर आपने चेतावनी के आधारभूत लेवल को कैप्चर करने के लिए, दूसरे टूल का इस्तेमाल किया है, तो नई चेतावनियों को ठीक करें और उनके आधारभूत लेवल को भी अपडेट करें.

अपनी बेसलाइन रिपोर्ट अपडेट करने के लिए, ./gradlew dependencyGuard चलाएं. इसके बाद, लाइब्रेरी से जुड़े बदलावों को देखने के लिए, अपनी VCS diff को चलाएं. इसमें आपकी उम्मीद से ज़्यादा लाइब्रेरी के अपग्रेड शामिल हो सकते हैं.

जोखिमों का विश्लेषण करना

यह जानने के बाद कि क्या बदलाव हुआ है, हर अपग्रेड की गई लाइब्रेरी के संभावित जोखिमों को ध्यान में रखें. इससे, आपको बदलावों की जांच करने या उन पर ज़्यादा बारीकी से नज़र रखने में मदद मिलती है. अपने प्रोजेक्ट के लिए, जोखिम का एक सेट तय करें, ताकि लगातार विश्लेषण किया जा सके.

इन बातों का ध्यान रखें:

मेजर वर्शन में होने वाले बदलाव

क्या मेजर वर्शन का नंबर बदला है?

सेमेंटिक वर्शनिंग में, पहले नंबर को मेजर वर्शन कहा जाता है. उदाहरण के लिए, अगर किसी लाइब्रेरी का वर्शन 1.2.3 से 2.0.1 पर अपग्रेड किया गया है, तो इसका मतलब है कि मुख्य वर्शन बदल गया है. आम तौर पर, यह इस बात का संकेत होता है कि लाइब्रेरी डेवलपर ने वर्शन के बीच काम न करने वाले बदलाव किए हैं. जैसे, एपीआई के कुछ हिस्सों को हटाना या उनमें बदलाव करना.

यह मैसेज दिखने पर, इनमें से किसी भी बात का ध्यान रखते समय, उन लाइब्रेरी पर ज़्यादा ध्यान दें जिन पर असर पड़ा है.

अगर आपका कोड किसी एक्सपेरिमेंटल एपीआई का इस्तेमाल करता है (जिसके लिए आपको अक्सर एनोटेशन या बिल्ड-फ़ाइल की खास बातों का इस्तेमाल करके ऑप्ट-इन करना पड़ता है), तो 1.2.3 से 1.3.1 या 1.2.3 से 1.2.5 पर अपग्रेड करने जैसे छोटे या पैच वाले वर्शन में बदलाव करने पर भी, अतिरिक्त जोखिम हो सकते हैं.

अस्थिर एपीआई

लाइब्रेरी की कुछ रिलीज़ में ऐसे एपीआई शामिल हो सकते हैं जो पूरी तरह से काम नहीं करते. आम तौर पर, ये ऐसे एपीआई होते हैं जो अभी काम में हैं या किसी ऐसे एपीआई पर निर्भर हैं जो ठीक से काम नहीं करता.

आम तौर पर, ये लाइब्रेरी सिर्फ़ झलक के तौर पर उपलब्ध होती हैं. जैसे, अल्फा, डेवलपर या प्रयोग के तौर पर रिलीज़ की गई लाइब्रेरी. हालांकि, कुछ लाइब्रेरी में ऐसे एपीआई भी शामिल होते हैं जिन्हें प्रयोग के तौर पर या अस्थिर के तौर पर मार्क किया गया हो.

अगर हो सके, तो ऐसे एपीआई इस्तेमाल न करें. अगर आपको इनका इस्तेमाल करना है, तो अपने इस्तेमाल को रिकॉर्ड करना न भूलें. साथ ही, बाद के रिलीज़ में होने वाले बदलावों या इनके हटने पर नज़र रखें.

डाइनैमिक व्यवहार

कुछ लाइब्रेरी, बाहरी वजहों के आधार पर अलग तरह से काम करती हैं. उदाहरण के लिए, कोई लाइब्रेरी जो किसी सर्वर से इंटरैक्ट करती है वह उस सर्वर में होने वाले बदलावों पर निर्भर करती है.

  • क्या लाइब्रेरी को किसी खास सर्वर वर्शन से मैच करना ज़रूरी है?
  • क्या लाइब्रेरी, सर्वर के अलग-अलग वर्शन से कनेक्ट हो सकती है?
  • क्या किसी अन्य बाहरी फ़ैक्टर से लाइब्रेरी के सही तरीके से काम करने पर असर पड़ता है?

मेनिफ़ेस्ट मर्ज करना

Android संग्रह (एएआर) के तौर पर पब्लिश की गई लाइब्रेरी में ऐसे संसाधन और मेनिफ़ेस्ट शामिल हो सकते हैं जिन्हें आपके ऐप्लिकेशन में मर्ज किया जाता है. ये नई अनुमतियां और Android कॉम्पोनेंट जोड़ सकते हैं. जैसे, ऐसी गतिविधियां या ब्रॉडकास्ट रिसीवर जो सीधे तौर पर नहीं चलती हैं.

रनटाइम के दौरान होने वाले अपडेट

कुछ लाइब्रेरी ऐसी सुविधाओं का इस्तेमाल करती हैं जिन्हें आपके ऐप्लिकेशन के कंट्रोल से बाहर अपडेट किया जा सकता है. कोई लाइब्रेरी, Play services का इस्तेमाल कर सकती है. इसे Android SDK टूल से अलग से अपग्रेड किया जाता है. अन्य लाइब्रेरी, स्वतंत्र रूप से अपडेट किए गए बाहरी ऐप्लिकेशन (आम तौर पर AIDL का इस्तेमाल करके) में सेवाओं से बंधी हो सकती हैं.

आपको कितने वर्शन छोड़ने हैं?

लाइब्रेरी को अपग्रेड करने में जितनी ज़्यादा देरी की जाएगी, उतने ही ज़्यादा जोखिम होंगे. अगर आपको किसी वर्शन में काफ़ी बदलाव दिखता है, जैसे कि 1.2.3 से 1.34.5, तो इस लाइब्रेरी पर ज़्यादा ध्यान दें.

डेटा को दूसरी जगह भेजने से जुड़ी गाइड

देखें कि लाइब्रेरी में डेटा को दूसरी जगह भेजने से जुड़ी गाइड है या नहीं. इससे, जोखिम का विश्लेषण करने और उसे कम करने की प्लानिंग करने में काफ़ी मदद मिलती है.

ध्यान दें कि इस तरह की गाइड का होना इस बात का एक अच्छा संकेत है कि डेवलपर ने, ऐप्लिकेशन के साथ काम करने की सुविधा पर ध्यान दिया है. साथ ही, आपके ऐप्लिकेशन को अपग्रेड करने से जुड़ी समस्याओं को हल करने के बारे में सोचा है.

रिलीज़ नोट

बदली गई हर लाइब्रेरी के लिए, रिलीज़ नोट देखें (अगर उपलब्ध हों). बदलावों या नई ज़रूरी शर्तों के बारे में जानकारी देखें. जैसे, जोड़ी गई अनुमतियां.

README

लाइब्रेरी के लिए कुछ 'रीड मी' फ़ाइलों में संभावित जोखिमों के बारे में बताया जाता है. ऐसा तब किया जाता है, जब लाइब्रेरी में रिलीज़ नोट न दिए गए हों. _पहले से मौजूद समस्याओं_ को देखें. खास तौर पर, सुरक्षा से जुड़ी समस्याओं को देखें.

पहले से पता चली हुई कमजोरियों की जांच करना

Play SDK Index, कई लोकप्रिय SDK टूल के लिए जोखिम ट्रैक करता है. Play Console से यह पता चलता है कि आपने सूची में शामिल ऐसे किसी एसडीके टूल का इस्तेमाल किया है या नहीं जिसमें पहले से मौजूद जोखिम हैं. Android Studio में बिल्ड फ़ाइलों में बदलाव करते समय, आईडीई, SDK इंडेक्स की जांच करता है और जोखिम वाली लाइब्रेरी के वर्शन के इस्तेमाल को फ़्लैग करता है.

नैशनल इंस्टिट्यूट ऑफ़ स्टैंडर्ड्स ऐंड टेक्नोलॉजी (एनआईएसटी) एक बड़ा नैशनल वुल्नरबिलिटी डेटाबेस (एनवीडी) मैनेज करता है. डिपेंडेंसी की जांच करने वाला Gradle प्लग इन, इस्तेमाल की गई डिपेंडेंसी की जांच NVD के हिसाब से करता है.

डिपेंडेंसी जांचने की सुविधा का इस्तेमाल करने के लिए, NVD API पासकोड का अनुरोध करें, Gradle प्लग इन सेट अप करें, और ./gradlew dependencyCheckAnalyze चलाएं. ध्यान दें कि इसमें काफ़ी समय लग सकता है.

वर्शन से जुड़े विवाद

क्या वर्शन उम्मीद के मुताबिक रिज़ॉल्व हो रहे हैं? कॉन्फ़िगरेशन में अंतर देखें. खास तौर पर, वर्शन में बड़े अंतर देखें. टकरावों का पता लगाने के तरीके के बारे में जानने के लिए, Gradle डिपेंडेंसी रिज़ॉल्यूशन देखें. खास तौर पर, ./gradlew app:dependencies रिपोर्ट में -> खोजें.

अगर हो सके, तो डिपेंडेंसी के लेखकों के साथ मिलकर काम करें, ताकि उनकी डिपेंडेंसी में कोई विरोध न हो. अगर आपकी कंपनी की अनुमति है, तो लाइब्रेरी के साथ काम करने वाले ऐप्लिकेशन की संख्या बढ़ाने के लिए, लाइब्रेरी में बदलाव करें (अपस्ट्रीमिंग).

लाइसेंस की जांच करना

लाइब्रेरी को अपग्रेड करते समय, लाइसेंस में हुए बदलावों को देखें. लाइब्रेरी का लाइसेंस, अपने-आप किसी ऐसे लाइसेंस में बदल सकता है जो आपके ऐप्लिकेशन या लाइब्रेरी के साथ काम नहीं करता. ट्रांज़िशनरी डिपेंडेंसी की नई सुविधा से, काम न करने वाले लाइसेंस भी शामिल हो सकते हैं. अपनी सभी डिपेंडेंसी के लाइसेंस के मौजूदा सेट की जांच करने के बारे में जानने के लिए, लाइसेंस की पुष्टि करें लेख पढ़ें.

मेंटेनेंस और
क्वालिटी से जुड़े जोखिम

सार्वजनिक रिपॉज़िटरी वाली लाइब्रेरी के लिए:

  • लाइब्रेरी को कितने योगदानकर्ता मैनेज कर रहे हैं?
  • आखिरी बार अपग्रेड कब किया गया था और लाइब्रेरी कितनी बार बदलती है?
  • समस्या का बैकलॉग (अगर उपलब्ध हो) कैसा दिखता है? लाइब्रेरी की संभावित समस्याओं और तकनीकी बकाया को समझने के लिए, इसे स्किम करें.
  • यूनिट टेस्ट, लाइब्रेरी को कितनी अच्छी तरह कवर करते हैं?
  • क्या कोडबेस में एंटी-पैटर्न मौजूद हैं?
  • क्या लाइब्रेरी के बारे में अच्छी तरह से जानकारी दी गई है?
  • क्या कोडबेस में _fixme_ वाली कई टिप्पणियां हैं?

ओपन सोर्स बनाम क्लोज़्ड सोर्स

अगर कोई लाइब्रेरी ओपन सोर्स है, तो क्लोज़्ड सोर्स की तुलना में समस्याओं को डीबग करना आसान होगा. भले ही, समस्याएं आपके कोड या लाइब्रेरी कोड में हों.

क्लोज़्ड सोर्स डिपेंडेंसी को कम से कम करें और उनके मूल्यांकन के दौरान ज़्यादा जांच करें. क्या आपके इस्तेमाल के उदाहरण के हिसाब से, अच्छे विकल्प उपलब्ध हैं? क्लोज़्ड सोर्स लाइब्रेरी के लिए, सेवा स्तर के कौनसे समझौते उपलब्ध हैं? अगर आपको क्लोज़्ड सोर्स डिपेंडेंसी का इस्तेमाल करना है, तो जोखिम को कम करने के लिए ज़्यादा टेस्ट केस लिखने के लिए तैयार रहें.

बिल्ड चलाना

अपना प्रोजेक्ट बनाएं. नई गड़बड़ियां या चेतावनियां देखें. अगर आपको पता चलता है कि ये गड़बड़ियां किस लाइब्रेरी की वजह से हो रही हैं, तो उस लाइब्रेरी को अपग्रेड करने के जोखिम के बारे में ध्यान रखें.

अगर आपको मंदी से जुड़ी कोई नई चेतावनी दिखती है, तो उन्हें लाइब्रेरी के लिए खास जोखिम के तौर पर जोड़ें. इन्हें बाद की रिलीज़ में हटाया जा सकता है. अगर आपको उस लाइब्रेरी का इस्तेमाल जारी रखना है, तो बंद किए गए एपीआई का इस्तेमाल करने के बजाय, उनके बदले इस्तेमाल किए जा रहे एपीआई का इस्तेमाल शुरू करें. इसके अलावा, बंद किए गए एपीआई को नोट करके, उन फ़ंक्शन पर नज़र रखें और देखें कि उन्हें बाद में हटाया गया है या नहीं.

एपीआई से जुड़ी समस्याओं का पता लगाने के लिए, lint का इस्तेमाल करना

Android lint आपके ऐप्लिकेशन में कई समस्याओं का पता लगा सकता है. इनमें, कुछ ऐसी समस्याएं भी शामिल हैं जो डिपेंडेंसी या Android SDK टूल के वर्शन में बदलाव होने की वजह से होती हैं. उदाहरण के लिए, अगर आपने compileSdk को अपग्रेड किया है और इसके नए एपीआई का इस्तेमाल किया है, तो lint उन एपीआई की शिकायत करता है जो SDK टूल के पुराने वर्शन में उपलब्ध नहीं हैं.

Lint, Android Studio एडिटर में चलता है. इसमें बदलाव करने पर, समस्याओं की रिपोर्टिंग की जाती है. हालांकि, आम तौर पर यह Studio में आपके बिल्ड के हिस्से के तौर पर नहीं चलता. साथ ही, कमांड-लाइन बिल्ड चलाने पर भी यह तब तक नहीं चलता, जब तक build या lint टारगेट का इस्तेमाल नहीं किया जाता.

अगर कंटिन्यूअस इंटिग्रेशन (सीआई) का इस्तेमाल किया जा रहा है, तो इस तरह की गड़बड़ियों का पता लगाने के लिए, सीआई बिल्ड के दौरान (या कम से कम हर रात के बिल्ड के दौरान) gradlew build या gradlew lint चलाएं.

अगर सीआई का इस्तेमाल नहीं किया जा रहा है, तो कम से कम कभी-कभी gradlew lint चलाना न भूलें.

लिंट की गड़बड़ियों और चेतावनियों पर खास ध्यान दें. कुछ लाइब्रेरी, अपनी लिंट जांच के साथ शिप की जाती हैं. इससे, उनके एपीआई के सही इस्तेमाल की पुष्टि करने में मदद मिलती है. लाइब्रेरी के कुछ नए वर्शन में, नई लिंट चेतावनियां और गड़बड़ियां शामिल होती हैं. इस वजह से, बिल्ड करने पर नई रिपोर्ट जनरेट होती हैं.

जोखिम कम करना

अपग्रेड से जुड़े जोखिम का पता लगाने के बाद, यह तय करें कि उन्हें कैसे कम किया जाए:

  • कुछ जोखिमों को स्वीकार करें. कुछ जोखिम इतने कम होते हैं कि उन्हें स्वीकार किया जा सकता है. ऐसा तब ज़्यादा होता है, जब अपग्रेड में लगने वाला समय और संसाधन सीमित हों.
  • कुछ जोखिमों को पूरी तरह से खारिज कर दें. कुछ अपग्रेड बहुत जोखिम भरे लग सकते हैं. ऐसा तब होता है, जब आपके पास इस समय उन्हें कम करने के लिए सीमित समय या संसाधन हों. अगर आपको प्राथमिकता तय करनी है, तो उन अपग्रेड पर फ़ोकस करें जो आपको मिले बग ठीक करने के लिए ज़रूरी हैं या जिन नई सुविधाओं की आपको ज़रूरत है.
  • बाकी जोखिम कम करना
    • अपने अपग्रेड को बदलावों के छोटे और अलग-अलग सेट में बांटें. इससे, पूरी प्रोसेस में होने वाले जोखिम को कम करने के साथ-साथ, कुछ हिस्से को रोलबैक करने की सुविधा मिलती है.
    • बदलावों की पूरी जांच करें.
    • अचानक हुए बदलावों की जांच करने के लिए, अपने ऐप्लिकेशन की जांच करें. अपग्रेड में भरोसा बढ़ाने के लिए, जहां ज़रूरी हो वहां नए टेस्ट जोड़ें.
    • अगर आपको कोई संदिग्ध जानकारी मिलती है, तो सोर्स देखें (अगर उपलब्ध हो).
    • अपने सोर्स या बिल्ड में ज़रूरी बदलाव करें.

अपने फ़ैसलों की जानकारी दस्तावेज़ में रखें. अगर अपग्रेड से जुड़े जोखिम, आपके ऐप्लिकेशन को चलाने के दौरान समस्याएं बन जाते हैं, तो जोखिम के विश्लेषण का दस्तावेज़ तैयार करने से, गड़बड़ी के ज़रूरी विश्लेषण को कम किया जा सकता है.

लाइसेंस की पुष्टि करना

लाइब्रेरी डेवलपर, लाइब्रेरी का लाइसेंस आपके इस्तेमाल के लिए देते हैं. आपको लाइसेंस की शर्तों का पालन करना होगा. ऐसा न करने पर, लाइब्रेरी का इस्तेमाल नहीं किया जा सकेगा. कुछ लाइसेंस बहुत ज़्यादा आसान होते हैं. इनमें अक्सर लाइब्रेरी के एट्रिब्यूशन और असली उपयोगकर्ताओं को लाइसेंस का टेक्स्ट दिखाने की ज़रूरत होती है. कुछ लाइब्रेरी को वायरल माना जाता है. अगर उन लाइब्रेरी का इस्तेमाल किया जाता है, तो आपको अपने ऐप्लिकेशन या लाइब्रेरी पर भी वही लाइसेंस लागू करना होगा.

किसी भी रिलीज़ के साथ लाइसेंस बदल सकते हैं. जब भी अपग्रेड करें, तो आपको पुष्टि करनी चाहिए कि इस्तेमाल की जा रही डिपेंडेंसी का लाइसेंस, आपके ऐप्लिकेशन या लाइब्रेरी के साथ काम करता हो.

अगर लाइसेंस काम नहीं करता है या अब काम नहीं करता है, तो लाइसेंस के उस वर्शन का इस्तेमाल नहीं किया जा सकता. यहां आप:

  • लाइब्रेरी के मालिक से संपर्क करें और मौजूदा लाइसेंस को जारी रखने का अनुरोध करें. इसके अलावा, पुराने लाइसेंस का इस्तेमाल जारी रखने के लिए, ड्यूअल लाइसेंस का अनुरोध भी किया जा सकता है.
  • अपनी कानूनी टीम के साथ मिलकर यह तय करें कि आपके पास अपने लाइसेंस को,
  • काम करने वाले लाइसेंस वाली कोई दूसरी लाइब्रेरी ढूंढें और ज़रूरत के हिसाब से अपने ऐप्लिकेशन में बदलाव करें.
  • लाइब्रेरी के उस वर्शन को फ़ॉर्क करें जो आपके डिवाइस पर काम करता हो. ऐसा तब करें, जब लाइसेंस में डेरिवेटिव बनाने की अनुमति हो और बदलावों का असर पुराने वर्शन पर न पड़ता हो. इसके बाद, उसमें अपने हिसाब से बदलाव करें.