लाइब्रेरी क्रेट में ब्रेकिंग चेंज को वास्तव में क्या माना जाता है?

Question

जंग के टुकड़े Semantic Versioning का उपयोग करते हैं। नतीजतन, एक ब्रेकिंग बदलाव के साथ प्रत्येक रिलीज के परिणामस्वरूप एक प्रमुख संस्करण टक्कर होनी चाहिए। ब्रेकिंग चेंज को आमतौर पर कुछ ऐसा माना जाता है जो डाउनस्ट्रीम क्रेट्स को तोड़ सकता है (कोड पुस्तकालय पर निर्भर करता है)।

हालांकि, जंग में पूरी तरह से डाउनस्ट्रीम क्रेट को तोड़ने की क्षमता है। उदाहरण के लिए, बदलना (को में जोड़कर) सार्वजनिक प्रतीकों का सेट संभवतः एक तोड़ने वाला परिवर्तन है, क्योंकि डाउनस्ट्रीम क्रेट्स ग्लोब-आयात (use foo::*;) का उपयोग कर सकते हैं ताकि हमारी लाइब्रेरी के प्रतीकों को उनके नामस्थान में खींच सकें। इस प्रकार, प्रतीकों को जोड़ने से निर्भर क्रेट भी टूट सकते हैं; this example देखें।

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

क्या इस बारे में कोई दिशानिर्देश है? क्या एक ब्रेकिंग बदलाव और वास्तव में क्या माना जाता है (क्योंकि इसे "उपयोगकर्ता की गलती" माना जाता है)?

Answer 1

इस विषय पर एक जंग आरएफसी है: RFC 1105: API Evolution। यह किसी भी जंग पुस्तकालय परियोजना पर लागू होता है, और इसमें सभी प्रकार के परिवर्तन शामिल होते हैं (न केवल परिवर्तन तोड़ते हैं) और वे अर्थपूर्ण संस्करण को कैसे प्रभावित करते हैं। मैं इस उत्तर को केवल एक लिंक-उत्तर देने के लिए आरएफसी के प्रमुख बिंदुओं को सारांशित करने का प्रयास करूंगा। :)

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

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

---

बड़े बदलाव आरएफसी (commit 721f2d74 के रूप में) में परिभाषित कर रहे हैं:

• केवल रात को संकलक के साथ संगत किया जा रहा करने के लिए स्थिर संकलक के साथ संगत किया जा रहा से अपनी परियोजना स्विचिंग।
• मॉड्यूल में किसी भी सार्वजनिक item का नामकरण, स्थानांतरण या निकालना।
• सभी मौजूदा फ़ील्ड सार्वजनिक होने पर संरचना में एक निजी फ़ील्ड जोड़ना।
• किसी ऐसे क्षेत्र में सार्वजनिक क्षेत्र जोड़ना जिसमें निजी क्षेत्र नहीं हैं।
• एक enum में नए रूपों को जोड़ना।
• एक enum संस्करण में नए फ़ील्ड जोड़ना।
• एक विशेषता के लिए एक गैर-डिफ़ॉल्ट आइटम जोड़ना।
• किसी विशेषता आइटम के हस्ताक्षर में कोई भी गैर-मामूली परिवर्तन।
• किसी मौजूदा प्रकार पर fundamental विशेषता लागू करना।
• मौजूदा प्रकार पैरामीटर पर कसकर सीमाएं।
• फ़ंक्शन में तर्क जोड़ना या निकालना।
• कोई अन्य तोड़ने वाला परिवर्तन जो आरएफसी में मामूली परिवर्तन के रूप में सूचीबद्ध नहीं है।

नाबालिग आरएफसी में परिभाषित किया गया परिवर्तन (commit 721f2d74 के रूप में, जब तक निर्दिष्ट तोड़ने) कर रहे हैं:

• कार्गो के उपयोग बदलकर एक टोकरे पर पेश करता है।
• मॉड्यूल में नए सार्वजनिक आइटम जोड़ना।
• संरचना में निजी फ़ील्ड जोड़ना या निकालना जब कम से कम एक पहले से मौजूद है (परिवर्तन से पहले और बाद में) [ब्रेक नहीं]।
• सभी निजी क्षेत्रों (कम से कम एक फ़ील्ड के साथ) को सामान्य संरचना में या इसके विपरीत, एक टुपल स्ट्रक्चर चालू करना।
• एक विशेषता के लिए एक डिफ़ॉल्ट आइटम जोड़ना।
• एक विशेषता [0 ब्रेकिंग] पर एक डिफ़ॉल्ट प्रकार पैरामीटर जोड़ना।
• किसी मौजूदा प्रकार पर किसी गैर-मौलिक विशेषता को कार्यान्वित करना।
• कोई भी आइटम किसी अंतर्निहित impl पर जोड़ना।
• किसी फ़ंक्शन के अनियंत्रित व्यवहार को बदलना।
• किसी मौजूदा प्रकार पैरामीटर पर ब्रेकिंग सीमा [0 ब्रेकिंग नहीं]।
• किसी प्रकार या विशेषता [0 ब्रेकिंग] पर डिफॉल्ट प्रकार पैरामीटर जोड़ना।
• किसी प्रकार के नए प्रकार पैरामीटर द्वारा अपने प्रकार को प्रतिस्थापित करके मौजूदा स्ट्रक्चर या एनम फ़ील्ड को सामान्यीकृत करना जो पिछले प्रकार पर डिफ़ॉल्ट है [issue 27336 तक तोड़ना तय है]।
• किसी मौजूदा फ़ंक्शन में एक नया प्रकार पैरामीटर पेश करना।
• किसी प्रकार के पैरामीटर या किसी मौजूदा प्रकार के रिटर्न प्रकार को एक नए प्रकार के पैरामीटर द्वारा प्रतिस्थापित करके जिसे पिछले प्रकार के लिए तत्काल किया जा सकता है।
• नई लिंट चेतावनियों/त्रुटियों का परिचय।

स्पष्टीकरण और उदाहरणों के लिए the RFC देखें।