क्या "बैकपोर्टिंग" शब्द के विपरीत है?

Question

जैसा कि मैं समझता हूं, "बैकपोर्टिंग" शब्द का उपयोग एक फिक्स का वर्णन करने के लिए किया जाता है जिसे भविष्य के संस्करण में लागू किया जाता है जिसे पिछले संस्करण में भी पोर्ट किया जाता है। विकिपीडिया की परिभाषा इस प्रकार है:

बैकपोर्टिंग एक निश्चित सॉफ्टवेयर संशोधन (पैच) लेने की क्रिया है और इसे सॉफ्टवेयर के पुराने संस्करण पर लागू करने की तुलना में इसे शुरू के लिए बनाया गया था। यह एक सॉफ्टवेयर विकास प्रक्रिया में रखरखाव कदम का हिस्सा है ...

उदाहरण के लिए:

• एक समस्या खोज की है और V2.0 में तय की गई है। उसी फिक्स को पोर्ट किया जाता है और V1.5 पर लागू किया जाता है।

जब विपरीत दिशा में यह किया जाता है तो क्या शब्द है?

• समस्या की खोज की और V1.5 में तय की गई है। उसी फिक्स को पोर्ट किया जाता है और V2.0 पर लागू किया जाता है।

क्या "बैकपोर्टिंग" शब्द अभी भी लागू होगा? या क्या "फॉरवर्डपोर्टिंग" (जो कि "पोर्ट फ़ॉरवर्डिंग" की तरह बहुत अच्छा लगता है) एक शब्द है?

Comments

"प्रचार" के बारे में क्या?

— गिल बेट्स

Answer 1

यह एक बैकस्लैश के विपरीत के समान है। हर कोई इसे फॉरवर्ड स्लैश कहना चाहता है, लेकिन वास्तव में यह सिर्फ एक "स्लैश" है। बैकपोर्टिंग का विपरीत "पोर्टिंग" है।

Comments

"पोर्टिंग" एक अधिक सामान्य शब्द है और किसी भी कोड ट्रांसफर पर लागू हो सकता है, यहां तक ​​कि भाषाओं के बीच भी। मेरी कंपनी में हम इस प्रश्न में वर्णित विशिष्ट मामले के लिए "फॉरवर्ड-पोर्टिंग" का उपयोग करते हैं।

— मार्को टोपोलनिक

Answer 2

यह आम तौर पर ऐसा नहीं होता है जैसा कि आप V2.0 कोडबेस में कहा गया मुद्दा ठीक करेंगे, और वैकल्पिक रूप से इसे बैकपोर्ट करेंगे। :) संस्करण नियंत्रण के संदर्भ में, यह बस कहा जाता है merging।

Comments

ऐसा इसलिए होता है क्योंकि V1.x और V2.x सह-अस्तित्व और समानांतर में बनाए रखा जाता है, प्रत्येक अपनी स्वयं की रखरखाव शाखा पर। एक क्रॉस-संस्करण बग को खोजा जा सकता है और किसी भी तरफ तय किया जा सकता है।

— मार्को टोपोलनिक

यदि V1.5 पहले से ही जारी है, लेकिन भविष्य में V2.0 जारी किया जाएगा, तो आप सबसे पहले V1.5 में समस्या को ठीक करते हैं, क्योंकि यह संस्करण पहले से ही ग्राहकों द्वारा उपयोग किया जाता है और इसे ठीक करने की अधिक आवश्यकता है। बाद में आप फिक्स को V2.0 पर पोर्ट करें।

— user1364368

@ user1364368 रिलीज मैनेजमेंट एक ऑर्थोगोनल चिंता है। यह कोडबेस के सबसे हाल के संस्करण में बग को ठीक करने के लिए अधिक समझ में आता है क्योंकि इसमें अधिक जानकारी शामिल है (इसका परिवर्तन इतिहास पुराने संस्करण के परिवर्तन इतिहास का एक सुपरसेट है)। इसके बारे में एक अलग तरीके से सोचें: यह अवहेलना करें कि परिवर्तन बग से संबंधित है। क्या आप अभी भी पुराने संस्करण में परिवर्तन करना पसंद करेंगे? क्या आप कहते हैं, कोडबेस के पुराने संस्करण में सुविधा विकास शुरू कर सकते हैं? यह बहुत जल्दी एक निरर्थक, पिछड़े-पुनरावर्ती विकास की रणनीति को कम कर देता है

— awdz9nld

@ मार्टिनकमैन एक राज्य में कोडबेस के प्रमुख (V2.0 के लिए) (वर्तमान विकास कार्य के कारण) हो सकता है जो इसे ठीक करने की अनुमति नहीं देता है। कोडबेस के सिर को फिर से साफ करने में कई दिन या हफ्ते लग सकते हैं, लेकिन आप आपातकालीन सुधार के लिए इतने लंबे समय तक इंतजार नहीं कर सकते।

— user1364368

Answer 3

मुझे लगता है कि मैं शब्दों का उपयोग करूंगा: भविष्य-प्रूफिंग या, वैकल्पिक रूप से, आगे संगतता :

विकिपीडिया के भविष्य-प्रमाण से :

भविष्य के प्रमाण: वाक्यांश भविष्य के प्रमाण भविष्य के घटनाक्रमों की आशा करने की कोशिश करने की विशेष प्रक्रिया का वर्णन करता है, ताकि संभावित नकारात्मक परिणामों को कम करने और अवसरों को जब्त करने के लिए कार्रवाई की जा सके।

और आगे-संगतता :

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

या दोनों "भविष्य-प्रूफ़िंग फॉर फ़ॉरवर्ड-कम्पैटिबिलिटी"।

ओह, बुलबुलरी :)

Answer 4

विपरीत दिशा में बैकपोर्टिंग केवल पोर्टिंग है , लेकिन आपके द्वारा वर्णित संदर्भ में ऐसा करने का कोई कारण नहीं है।

Answer 5

मुझे लगता है कि "बैकपोर्ट" शब्द केवल उसी प्रोग्राम के एक नए रिलीज की सुविधा को उसी प्रोग्राम के पुराने को लाने की कार्रवाई के लिए संदर्भित करता है, अभी भी इसका उपयोग करने के लाभों के लिए।

जब आप पुराने, बंद किए गए नए फ़ीचर को विकसित नहीं करते हैं, तो संस्करण "रिवर्स" बैकपोर्टिंग मौजूद नहीं है (यदि आप परिभाषा के अनुसार, संस्करण पुराना नहीं है)।

जिसे आप "फ़ॉरपोर्ट" कह रहे हैं, किसी समस्या को पुराने और नए शब्द दोनों में ठीक करना, एक छोटा बग़ीचा या पैच है।

Answer 6

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

Comments

जब तक आपका ग्राहक अब ठीक नहीं चाहता, तब तक सही है।

— एलेक्स आर।

Answer 7

मैं यहां एक उत्तर की तलाश में आया था क्योंकि मैं इस परिदृश्य के लिए एक प्रतिबद्ध टिप्पणी लिख रहा हूं। इस सामान्य स्थिति के लिए वास्तविक शब्दजाल की कमी को देखते हुए, मैं इसे "उत्पादन शाखा में विलय कर रहा हूँ" के रूप में जा रहा हूँ।