2015-05-30 12 views
10

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


मान लीजिए कि कोई उपयोगकर्ता पहले से ही मेरी लाइब्रेरी का संस्करण ए उपयोग कर रहा है। मैंने एक नया संस्करण बी

यदि वह बी के खिलाफ बिना किसी बदलाव के अपने कोड को संकलित कर सकता है और बी के साथ सही ढंग से चला सकता है, तो ए से बी में परिवर्तन स्रोत संगत कहा जाता है।

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

परिवर्तनों के लिए स्रोत संगत होने के लिए संभव है, लेकिन बाइनरी असंगत है। परिवर्तनों के असंगत और बाइनरी संगत होने के लिए परिवर्तन भी संभव है।

अर्थात् संस्करण के लिए मैं किस संगतता का उपयोग करता हूं? क्या मैं प्रमुख और मामूली/पैच अपडेट के बीच अंतर करने के लिए स्रोत संगतता का उपयोग करता हूं, या क्या मैं प्रमुख और मामूली/पैच अपडेट के बीच अंतर करने के लिए बाइनरी संगतता का उपयोग करता हूं?


मेरा वर्तमान प्रेरणा एक स्कैला लाइब्रेरी है। स्कैला बाइनरी संगतता का विश्लेषण करना बहुत मुश्किल हो सकता है और संकलक विवरण की अच्छी समझ की आवश्यकता होती है। स्रोत संगतता और बाइनरी असंगत बहुत आम है।

यह कुछ विचित्र एज केस नहीं है; यह समस्या किसी भी संकलित, गतिशील रूप से जुड़ी भाषा में दिखाई दे सकती है।

उत्तर

6

कुछ महीने बाद, मुझे लगता है कि मेरे पास एक अच्छा निष्कर्ष है।

अर्थपूर्ण संस्करण दोनों पर विचार करना चाहिए, और "सबसे बदले" का पालन करना चाहिए।

  • ब्रेकिंग स्रोत संकलन लाइब्रेरी के उपयोगकर्ताओं के लिए एक असंगत परिवर्तन है।
  • ब्रेकिंग रनटाइम निष्पादन लाइब्रेरी के उपयोगकर्ताओं के लिए एक असंगत परिवर्तन है।

यदि स्रोत संगतता या बाइनरी संगतता में परिवर्तन होता है, तो इसे अर्थपूर्ण संस्करण के अनुसार - एक नया प्रमुख संस्करण होना चाहिए।

स्कैला के लिए मेरे मामले में, बाइनरी संगतता को कभी-कभी निर्धारित करना मुश्किल हो सकता है। कई जार एपीआई diffing उपकरण हैं, उदा। JDiff

0

इस प्रश्न का उत्तर देने के लिए, यह दिखाएं कि आप एक ऐसे उपयोगकर्ता हैं जो प्रोग्रामर नहीं हैं। उनके दृष्टिकोण से, स्रोत कोड बेकार है; वे इसे समझ में नहीं आते हैं और यह उनके लिए व्यर्थ है। दूसरी ओर, उनके पास ऑब्जेक्ट कोड वाली एक फ़ाइल है और वे जानते हैं कि इसे कहीं जाना है। केवल बाइनरी मामलों का संस्करण उनके लिए है।

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

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

संक्षेप में, प्रश्न के सबसे अच्छे उत्तर यह है कि यह दोनों पर लागू होता है उनमें से।

+1

स्रोत-संगतता का अर्थ है कि उपयोगकर्ता का कोड बिना परिवर्तन किए संकलित करता है, इसलिए उन उपयोगकर्ताओं के बारे में बात करना जो प्रोग्रामर नहीं हैं या स्रोत कोड के बारे में नहीं जानते हैं, यहां काफी बकवास लगता है। साथ ही, अलग-अलग वर्जनिंग स्कीम रखने से उपयोगकर्ता को प्रश्न सीधे ले जाया जाएगा - क्या मुझे संस्करण योजना या बाइनरी-संगतता अर्थशास्त्र के साथ संस्करण योजना का उपयोग करना चाहिए? – matz

+0

मेरे उत्तर में "pretend" शब्द नोट करें। ऐसे समय होते हैं कि प्रोग्रामर भी स्रोत कोड की परवाह नहीं करते हैं। मुझे संदेह है कि, हालांकि, आपकी टिप्पणी दी गई है कि आपको ऐसी चिंताओं हैं जो इस प्रश्न में नहीं बताई गई हैं। शायद मूल प्रश्न पर टिप्पणी में आपकी विशिष्ट समस्या का विस्तार करने के क्रम में है। – eh9

संबंधित मुद्दे