पदावनत विधि को हटाने से पहले कब तक प्रतीक्षा करें? [बन्द है]

Question

मैं एक सार्वजनिक एपीआई बनाए रख रहा हूं और एक विधि को अपग्रेड करना होगा।

विलोपन से पहले कितने महीनों / वर्षों / संस्करणों पर एक सामान्य नियम है कि मुझे एक विधि को चित्रित करना चाहिए?

Comments

सामान्य नियम यह है कि "जब तक आप और / या आपके ग्राहकों को इसकी आवश्यकता हो, तब तक इसे अपने पास रखें।"

— रॉबर्ट हार्वे

"जनता" को परिभाषित करें। नि: शुल्क, ओपन सोर्स सॉफ्टवेयर, "अपने स्वयं के जोखिम पर उपयोग" अस्वीकरण के साथ? या बेचा सॉफ्टवेयर जहां एक अनुबंध मौजूद है?

— डॉक्टर ब्राउन

यह बहुत कुछ इस बात पर निर्भर करता है कि आपके उपयोगकर्ता किस बाज़ार में हैं और वे आपको एपीआई के लिए पैसे दे रहे हैं या नहीं।

— 17 की 26

यह इस बात पर भी निर्भर करता है कि आपके पास इसे ह्रास करने के लिए "क्यों" है; क्या पुराना तरीका सुरक्षा जोखिम है? क्या आपने अभी एक कारण खोजा है कि पुराने तरीके मौलिक और अविश्वसनीय रूप से अस्थिर होने के कारण एक दुर्भाग्यपूर्ण डिजाइन निर्णय क्यों है? क्या पुराना तरीका अब पहले की तुलना में धीमा है? क्या आप अपने लक्ष्य प्रणाली (जैसे, एक एम्बेडेड सिस्टम) पर मेमोरी से बाहर चल रहे हैं और आप सचमुच उस पर दोनों एपीआई फिट नहीं कर सकते हैं? या क्या आपको सिर्फ एक "बेहतर" तरीका मिला है और आप अपने रखरखाव को कम करने के लिए पुराने कोड को साफ करना चाहते हैं?

— jrh

java.io.StringBufferInputStreamJDK 1.1 (1997?) के बाद से पदावनत इस सवाल का कोई अच्छा या गलत जवाब नहीं है। यह पिछड़ी अनुकूलता प्रदान करने की आपकी आवश्यकताओं पर निर्भर करता है।

— लैवि नो

Answer 1

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

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

Comments

डिप्रेसेशन जरूरी नहीं कि अंतिम निष्कासन के बारे में है, इसलिए निष्कासन के बिना अपव्यय व्यर्थ नहीं है (और अक्सर सही बात है अगर पिछड़ी संगतता महत्वपूर्ण है)। अक्सर यह बिंदु "हमारे पास अब बेहतर तरीका है, इससे अधिक कुछ नहीं है, इसलिए आपको इसे इस तरह से नहीं करना चाहिए"।

— cHao

@ हाहाओ यदि कुछ घटाया जाता है, तो आपको यह उम्मीद नहीं करनी चाहिए कि यह जारी रहेगा। मुझे लगता है कि यदि आप अपनी परियोजना में एक विशेष वक्तव्य देना चाहते हैं, जिसमें कहा गया है कि आप हटाए गए कार्यक्षमता को नहीं हटाएंगे, तो यह ठीक है लेकिन अन्यथा, हां यह निहित है कि अंततः निष्कासन होगा। मैं जो बात कर रहा हूं, वह यह है कि अगर आप इस तरह के आस-पास किसी प्रकार की कठोरता नहीं रखते हैं, तो लोगों को विश्वास हो सकता है कि ऐसा कभी नहीं होगा। यह जावा के हाल के संस्करणों के साथ आया है जहां एक दशक या उससे अधिक के लिए कार्यक्षमता को हटा दिया गया है जिसे अब हटा दिया जा रहा है।

— जिम्मीजम्स

@ CHao मैं एक परियोजना को अपनी पदावनत कार्यक्षमता को हटा देना चाहूंगा। न केवल उपयोगकर्ताओं को वास्तव में स्विच करने के लिए प्रेरित किया जा रहा है, बल्कि यह अन्य सुधारों के साथ दखलअंदाजी इंटरफेस को भी रोकता है।

— jpmc26

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

— जिमीजैम

मैं @JimmyJames के साथ सहमत होने के लिए झंकार करने जा रहा हूं कि पदावनत का तात्पर्य आसन्न निष्कासन से है। उपभोक्ता अवधि अस्थायी बैकवर्ड संगतता प्रदान करने के एक तरीके के रूप में मौजूद है ताकि उपभोक्ता नई कार्यक्षमता में माइग्रेट कर सकें। इस बात की बिलकुल उम्मीद नहीं की जानी चाहिए कि अपग्रेड की गई कार्यक्षमता अनिश्चित काल तक बनी रहेगी। अगर पुरानी कार्यक्षमता रहने वाली है, तो इसका कोई कारण नहीं है।

— एरिक किंग

Answer 2

यह पूरी तरह से इस बात पर निर्भर करता है कि आपने अपने उपयोगकर्ताओं को किस तरह की स्थिरता की गारंटी दी है, और आप अपने उपयोगकर्ताओं के लिए कितना दर्द चाहते हैं।

आदर्श रूप से, आपका API सेवर का उपयोग करता है ताकि किसी भी ब्रेकिंग परिवर्तन के कारण प्रमुख संस्करण संख्या में वृद्धि हो। व्यवहार में, यह लगभग कभी नहीं करना वांछनीय है। यदि आपका एपीआई कुछ पैकेज प्रबंधक के माध्यम से स्थापित किया गया है, तो आप एक ब्रेकिंग परिवर्तन के बाद एक नया पैकेज नाम बनाना चाह सकते हैं ताकि एक साधारण अपग्रेड संघर्ष (जैसे myapi2 v2.123.4बनाम myapi3 v3.2.1) का कारण न हो । यह अनावश्यक हो सकता है यदि आपका पैकेज प्रबंधक तंग संस्करण निर्भरता का समर्थन करता है (जैसे ~v2.120कि एक निर्भरता विनिर्देश शामिल नहीं है v3.*), लेकिन विभिन्न पैकेज नामों में यह लाभ है कि असंगत संस्करणों का उपयोग बहुत आसानी से किया जा सकता है। सेमेस्टर का उपयोग करते समय भी, एक अवक्षेपण अवधि होने के लिए समझदार हो सकता है।

सेवर हमेशा लागू नहीं होता है। फिर एक स्पष्ट स्थिरता नीति का संचार करना अधिक महत्वपूर्ण है। उदाहरण के लिए:

• बिना सूचना के प्रायोगिक सुविधाओं को हटाया जा सकता है।
• किसी भी समय सुरक्षा कारणों से सुविधाओं को हटाया जा सकता है।
• अन्य सुविधाओं को केवल हटाया जाएगा
  • … एक जारी संस्करण में पदावनत होने के बाद
  • ... जहां वह संस्करण कम से कम तीन महीने पुराना है
  • ... और प्रमुख संस्करण में एक टक्कर द्वारा चिह्नित किया जाएगा।

ऐसी नीतियां विशेष रूप से अच्छी तरह से काम करती हैं जब आपके पास नियमित रिलीज होती है ताकि एक वर्ष के लिए एक स्पष्ट पदावनति अवधि हो।

अपग्रेड के रूप में एपीआई के किसी भी हिस्से को चिह्नित करने के अलावा, आपको अपग्रेड को व्यापक रूप से ज्ञात करना चाहिए। उदाहरण के लिए:

• भविष्य के निर्देशों और पदावनतियों के बारे में अपने चैंज में एक सेक्शन रखें।
• इससे पहले कि आप पदावनत करें, और पर्याप्त आपत्तियाँ हैं या नहीं, यह देखने के लिए समुदाय को सुनें।
• संवाद करें कि इन परिवर्तनों से क्या लाभ होंगे। आपके उपयोगकर्ता आधार के आधार पर, समाचार पत्र, प्रस्तुतियाँ, ब्लॉग पोस्ट या प्रेस विज्ञप्ति उपयुक्त मीडिया हो सकते हैं। एक स्पिन होने के बाद “हम एक भयानक नई सुविधा पैदा कर रहे हैं! (जिसके लिए इसे व्यापक रूप से इस्तेमाल की जाने वाली पुरानी सुविधा को हटाने की आवश्यकता होती है) ”बिना संदर्भ के फीचर को हटाने की तुलना में थोड़ा कम निराशाजनक है।

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

Comments

इस वजह से डाउनवोट किया गया: Ideally, your API uses semver so that any breaking change causes the major version number to be incremented. In practice, it is desirable to do this almost never.यदि आप उस का पालन करते हुए कह रहे हैं कि आपको नए प्रमुख संस्करण को कभी नहीं पेश करना चाहिए तो ब्रेकिंग परिवर्तनों को इंगित करने के लिए सेमर का उपयोग करने का क्या मतलब है?

— मर्समन

क्या वास्तव में एक बड़ा बदलाव होने पर पैकेज का नाम बदलना एक अच्छा विचार है? यही संस्करण संख्या के लिए हैं। मुझे नफरत है जब वे भी उनका नाम बदल देते हैं, यह वास्तव में मेवेन निर्भरता प्रबंधन को गड़बड़ कर देता है।

— एजेपेरेस

@AJPerez मैं समझता हूं कि यह आदर्श नहीं है, लेकिन यह बड़े निर्भरता के साथ संघर्षों को सकर्मक निर्भरता के साथ रोक सकता है: मैं कामेच्छा पर निर्भर करता हूं जो libconflict v1.2.3 पर निर्भर करता है, और मैं भी libbar पर निर्भर करता हूं जो libconflict v2.3.4 पर निर्भर करता है। फिर, मैं किसी भी लिबकंफ्लिक्ट संस्करण का चयन नहीं कर सकता हूं जो सभी निर्भरताओं को पूरा करता है - जब तक कि लिबकंफ्लिक्ट और लिंबकफ्लिक्ट 2 अलग पैकेज नहीं हैं। जावा के लिए विशेष रूप से, इस तरह के नामकरण से बी / सी कष्टप्रद है मुझे सभी आयातों को बदलना होगा। सौभाग्य से, जावा 9 (मॉड्यूल) परस्पर विरोधी संस्करणों का उपयोग करने का समर्थन करता है।

— अमोन

@mrsmn ब्रेकिंग परिवर्तन कष्टप्रद होते हैं लेकिन आप उन्हें पैकेज या नाम देते हैं। सेवर केवल इस समस्या के एक छोटे से हिस्से को संबोधित करता है: यह बताने में सक्षम है कि क्या उन्नयन कुछ भी तोड़ देगा। लेकिन एक बार जब आपके पास एक ब्रेकिंग परिवर्तन होता है, तब भी आपको इस बदलाव को समायोजित करने के लिए प्रयास करना होगा। इसलिए, यदि एपीआई जितना संभव हो उतना स्थिर रहने की कोशिश करता है तो यह बेहतर है। आदर्श रूप से उन्हें एक तरह से डिज़ाइन किया गया है ताकि उन्हें पीछे की संगतता को तोड़े बिना बढ़ाया जा सके।

— अमोन

@AJPerez हाँ। हाँ, यह अच्छा है। लोग हर समय संस्करण को खराब कर देते हैं। बग फिक्स (अनुमानित xxx ++) अक्सर टूट रहे हैं (अनुमानित x ++ xx)। अंक आमोन के रूप में बाहर आप (और मैं क्या मतलब है आप निर्भरता के उपयोगकर्ता के रूप में) एक समस्या है आप ठीक करना है। मुझे पता है कि मेरा कोड foo 3.2.1 के साथ काम करता है, यह foo 3.3.0 के साथ काम कर सकता है । मुझे पता है कि मेरा कोड foo के साथ काम करता है, यह foo-2 के साथ काम कर सकता है । मैं वीर्य का उपयोग करता हूं क्योंकि लोकप्रियता और यह प्रति सेगमेंट को नुकसान नहीं पहुंचाता है, लेकिन यह वास्तव में मेरे लिए स्पष्ट नहीं है कि यह आप सभी को खरीदता है।

— जेरेड स्मिथ

Answer 3

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

2015 में, Google के एंड्रॉइड ओएस पर stlport API के साथ एक समान समस्या थी। उन्होंने इसे हटा दिया था और इसे हटाना चाहते थे, लेकिन टन ऐप्स अभी भी इसका उपयोग कर रहे थे। उन्हें एक चतुर समाधान मिला:

अनिवार्य रूप से, उन्होंने किसी भी ऐप के बूटअप के दौरान 8 सेकंड की नींद () जोड़ी जो अभी भी डेवलपर्स के लिए एक उपयुक्त लॉग संदेश के साथ एपीआई का उपयोग करता है। एक महीने बाद, उन्होंने इसे दोगुना कर 16 सेकंड कर दिया। फिर एक और महीने बाद, वे एपीआई इंटरफ़ेस को सुरक्षित रूप से हटा सकते थे क्योंकि कोई भी इसका उपयोग करने से नहीं बचा था।

ऐसा करने का यह एक बहुत प्रभावी तरीका हो सकता है। एकमात्र वास्तविक मुद्दा यह है कि यदि आपका एपीआई बहुत पुराना है और उपभोक्ताओं को सक्रिय रूप से उपयोग किया है जो अब सक्रिय रूप से समर्थित नहीं हैं। दुर्भाग्य से, आप शायद ऐसे उपभोक्ताओं को स्वयं ठीक करने में सक्षम नहीं होंगे, लेकिन उस बिंदु पर आप वास्तव में विधि को हटाने और उपभोक्ता को तोड़ने से ज्यादा नहीं कर सकते।

Comments

प्यारा। बहुत प्यारा।

— डेविड हैमेन

Answer 4

पदावनत विधि प्रदान करने का न्यूनतम समय आपके एपीआई का उपयोग करके कार्यक्रमों के विकास चक्रों पर निर्भर करता है। बॉलपार्क आकृति के रूप में, 1 वर्ष पर्याप्त होना चाहिए।

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

मेरा सुझाव है कि जब आप हटाने से कुछ हासिल करते हैं तो आप पदावनत विधियों को हटा देते हैं :

• बग का पता लगाया जाता है जो विशेष रूप से पदावनत विधियों को प्रभावित करता है
• आप कोड को रिफलेक्टर करने वाले हैं और पदावनत विधियों को बनाए रखने के लिए महत्वपूर्ण प्रयास की आवश्यकता होगी
• आप अपने पुस्तकालय की आंतरिक संरचना का अनुकूलन कर रहे हैं, और पदावनत विधियाँ अब और उपयुक्त नहीं हैं।

हटाए गए तरीकों को सिर्फ इसलिए निकाल दिया क्योंकि वे एक्स महीनों / वर्षों के लिए पदावनत कर दिए गए थे या इसलिए कि आप बिना किसी अच्छे कारण के मनमाने ढंग से नुकसान पहुंचाने के लिए एक नया संस्करण राशि जारी कर रहे हैं।

Answer 5

पहले आपको विचार करना चाहिए कि क्या आप पदावनत या अप्रचलित हैं।

पदावनत का उपयोग उन तरीकों के लिए किया जाना चाहिए जो किसी तरह से हानिकारक हैं: सुरक्षा, प्रदर्शन, गलत परिणाम। आप उन्हें अपेक्षाकृत जल्दी से छुटकारा पाना चाहते हैं, 2 प्रमुख संस्करण से अधिक नहीं और 3 जी से चले गए। महत्वपूर्ण पर्याप्त समस्याओं के लिए, अगले लघु संस्करण में पदावनत हटाया जा सकता है।

अप्रचलित उन चीजों के लिए है जो किसी कारण से कम उपयोगी हैं, उदाहरण के लिए कम जानकारी देता है या साथ ही काम नहीं करता है, इसमें कई विकल्प और इसके बाद के संस्करण शामिल नहीं हैं। ये अनिश्चित काल तक घूम सकते हैं, लेकिन अगले प्रमुख संस्करण में कम से कम मौजूद होना चाहिए।

Comments

मैं कहता हूं कि गलत परिणाम देने वाली या सुरक्षा को नुकसान पहुंचाने वाली विधि को या तो तुरंत अक्षम कर दिया जाना चाहिए, या ठीक कर दिया जाना चाहिए। खराब प्रदर्शन के साथ एक विधि अनिश्चित काल तक घूम सकती है, जब तक कि कुछ उपयोगकर्ताओं के लिए इसका प्रदर्शन स्वीकार्य है।

— दिमित्री ग्रिगोरीव

@DmitryGrigoryev: एक एकल लघु संस्करण तुरंत के करीब है।

— जोर्मेनो

Answer 6

जवाब इस बात पर निर्भर करता है कि आप अपने ग्राहकों को किस तरह की सेवा दे रहे हैं।

चरम के एक छोर पर, विंडोज 3.1 में विन 3.1 युग से गलतियाँ हैं जो दो दशकों से प्रचारित हैं क्योंकि Microsoft बैकवर्ड संगतता में बहुत दृढ़ता से विश्वास करता था।

स्पेक्ट्रम के दूसरे छोर पर, कई वेब-ऐप एक अविकसित चेतावनी प्रदान किए बिना भी सुविधाओं को हटा देते हैं।

आपके ग्राहक आपके सॉफ़्टवेयर के लिए कितना भुगतान कर रहे हैं, यह अक्सर मायने रखता है, जैसा कि उनके काम की रेखा है। अनुसंधान वैज्ञानिक आमतौर पर, कहते हैं, बैंकरों या FAA की तुलना में प्रगति के मार्च के हिस्से के रूप में पदावनति स्वीकार करने के लिए तैयार हैं।

मैंने आंतरिक उपयोग के लिए सॉफ्टवेयर विकसित करने वाली कंपनी के लिए काम किया। मैंने वर्षों में कई समूहों का समर्थन किया। एक समूह के पास "किसी भी सुविधा को दूर करने वाली" मानसिकता नहीं थी। उन्हें 5-10 साल पहले फाइलों में वापस जाने की क्षमता की जरूरत थी और डेवलपर्स को फीचर्स वापस लाने के लिए बहुत तेजी से टाइमकाॅल पर उन पर विश्लेषण करना था। एक समूह का रवैया यह था कि "सुनिश्चित करें कि सभी अवक्षेपण पैच नोट्स में हैं, इसलिए हम बाद में उन्हें पा सकते हैं। " बीच में, हमारे पास एक समूह था जिसका नियम था "विशेषताओं को कम से कम 1 संस्करण के लिए एक मुद्रित चेतावनी के साथ चित्रित किया जाना चाहिए यदि उन्हें हटाने से पहले उनका उपयोग किया जाता है।" उस समूह के पास एक परीक्षण सूट था जो उन विशेषताओं को कवर करता था जिनकी उन्हें ज़रूरत थी। जब भी हम एक नया संस्करण जारी करते हैं, तो वे जल्दी से इसके खिलाफ अपना टेस्ट सूट चलाते हैं कि क्या कोई भी डिप्रेशन उन्हें परेशान करता है।

Answer 7

मैं एक सार्वजनिक एपीआई बनाए रख रहा हूं और एक विधि को अपग्रेड करना होगा।

आपको ऐसा करने की आवश्यकता क्यों है? क्या इसलिए कि चीजों को करने का एक नया चमकदार तरीका है, इसलिए पुरानी पद्धति अब हतोत्साहित है, लेकिन फिर भी ठीक काम करती है? या क्या पुरानी पद्धति को वास्तव में जाने की आवश्यकता है क्योंकि चीजें मौलिक रूप से बदल गई हैं?

• पुराना तरीका किसी भी वास्तविक समस्याओं के कारण नहीं है, तो और कर सकते हैं पर रुकने, तो यह रूप में अच्छी तरह हो सकता है। अगर नहीं तोड़ा है, तो इसे ठीक न करें। क्या आपको वास्तव में इसे हटाने की आवश्यकता है? शायद इसे अप्रचलित के रूप में चिह्नित करें, और प्रलेखन में एक नोट शामिल करें कि एक और विधि अधिक कुशल हो सकती है, या जो भी हो, लेकिन इसे जगह में छोड़ना शायद ठीक है।

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

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

(दूसरी दो बुलेट पॉइंट अन्य उत्तरों में अच्छी तरह से शामिल हैं, लेकिन मुझे लगता है कि पहला नया है।)

Answer 8

एक सार्वजनिक परियोजना के लिए, केवल इसे हटा दें यदि और केवल यदि आपको आवश्यकता हो तो।

जब आप अनावश्यक API निष्कासन करते हैं, तो आप कंपनियों और ठेकेदारों के लिए इस तरह से पैसे खर्च करते हैं कि आप मंथन मंथन के कारण भी गणना नहीं कर सकते।

कंपनियों और स्वतंत्र प्रोग्रामर को अपनी परियोजना का उपयोग बंद करना चाहते हैं? आवश्यक होने पर उनके सामान को पर्याप्त बार तोड़ें और आप कुछ ही समय में उस नाव में होंगे।

deprecation != eventual_removal। यदि कोई API खतरनाक है, तो आप उसे हटा देते हैं। यदि यह अभी पुराना है, तो इसे छोड़ दें और इसके प्रतिस्थापन का दस्तावेजीकरण करें।