आश्रित सॉफ्टवेयर घटकों के संस्करण क्रमांकन के लिए सर्वोत्तम अभ्यास की तलाश

Question

हम सॉफ्टवेयर घटकों के लिए संस्करण क्रमांकन करने के लिए एक अच्छा तरीका तय करने की कोशिश कर रहे हैं, जो एक दूसरे पर निर्भर हैं।

आइए और अधिक विशिष्ट बनें:

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

जब हम ड्राइवर में संगतता जाँच लागू कर रहे थे - यह जाँचता है कि फर्मवेयर संस्करण चालक के संस्करण के अनुकूल है या नहीं - हमने संस्करण संख्या के कई तरीकों पर चर्चा करना शुरू कर दिया है।

हम एक समाधान के साथ आए, लेकिन हमें यह भी लगा कि पहिया को फिर से मजबूत किया जाए। यही कारण है कि मैं प्रोग्रामर / सॉफ्टवेयर डेवलपर समुदाय से कुछ प्रतिक्रिया प्राप्त करना चाहता हूं, क्योंकि हमें लगता है कि यह एक सामान्य समस्या है।

तो यहाँ हमारा समाधान है:

हम व्यापक रूप से उपयोग किए जाने वाले प्रमुख.मिनोर.पैप वर्जन नंबरिंग का पालन करने और यहां तक ​​कि स्थिर / अप्राप्य संस्करणों के लिए विषम विषम संख्याओं का उपयोग करने की योजना बनाते हैं । अगर हम एपीआई में बदलाव करते हैं, तो हम मामूली संख्या में वृद्धि करेंगे।

इस सम्मेलन से निम्न उदाहरण की स्थिति पैदा होगी:

वर्तमान स्थिर शाखा 1.2.1 है और अस्थिर 1.3.7 है। अब, अस्थिर के लिए एक नया पैच एपीआई को बदल देता है, जिसके कारण नया अस्थिर संस्करण संख्या 1.5.0 हो जाएगी। एक बार, अस्थिर शाखा को स्थिर माना जाता है, चलो 1.5.3 में कहते हैं, हम इसे 1.4.0 के रूप में जारी करेंगे।

मुझे नीचे दिए गए संबंधित प्रश्नों में से किसी एक के उत्तर में खुशी होगी:

• क्या आप ऊपर वर्णित मुद्दों को संभालने के लिए एक सर्वोत्तम अभ्यास सुझा सकते हैं?
• क्या आपको लगता है कि हमारा "कस्टम" सम्मेलन अच्छा है?
• आप वर्णित सम्मेलन में क्या परिवर्तन लागू करेंगे?

Comments

स्थिर / अस्थिर पर आधारित संस्करण संख्याओं में वापस जा रहे हैं? कम से कम कहने के लिए भ्रामक। बस 1.4.0 के रूप में जारी नहीं किया है और 1.6.3 के रूप में 1.5.3 जारी किया है।

— मार्जन वेनमा

संस्करण क्रमांकन कैसे करना है, इसके लिए एक विनिर्देश है। इसे सिमेंटिक वर्जनिंग कहा जाता है ।

— Spoike

आपकी एप्लिकेशन संस्करण रणनीति

— Jörg W Mittag

इसे भी देखें: प्रोग्रामर.स्टैकएक्सचेंज.

— मार्टिन

@Spoike के लिए अपवोट करें। आपको अपनी टिप्पणी का जवाब देना चाहिए था! हम अंत में अर्थिंग वर्सनिंग का उपयोग करके बस गए।

— बिट-पाइरेट

Answer 1

IMHO संस्करण संख्याएं उत्पाद नामों की तरह हैं; महत्वपूर्ण यह है कि वे दृश्यमान हैं, लेकिन महत्वहीन हैं कि वे सामग्री के बजाय सजावट कर रहे हैं।

फिर भी एक उत्पाद नाम की तरह संस्करण संख्या, अर्थ वहन करती है। और सबसे महत्वपूर्ण बात जो आप कर सकते हैं वह है भ्रम से बचना। तो यहाँ संस्करण संख्या के संबंध में कुछ सामान्य अपेक्षाएँ हैं । इन अपवादों को पूरा नहीं करने पर, उपयोगकर्ता संभवतः भ्रमित हो जाएगा:

संस्करण संख्याएँ नीरस रूप से बढ़ रही हैं
यह संभवतः सबसे स्पष्ट अपेक्षा है, और साथ ही वास्तव में सच होने की कम से कम संभावना है। एट-ए-झलक, उपयोगकर्ता को उम्मीद है कि संस्करण 2.3.1 संस्करण 2.2.17 के बाद आता है , और इसमें एक ही या बेहतर तकनीक है। लेकिन निश्चित रूप से 2.3.x एक विकास शाखा है, और 2.2.x स्थिर है , और 2.3.5 वास्तव में 2004 में वापस जारी किया गया था और 2.2 शाखा अभी भी सक्रिय रूप से काम कर रही है और 2.2.17 पिछले अप्रैल में ही जारी किया गया था और इसमें शामिल है। .. खैर, आप विचार समझ गए। आप केवल संस्करण 2.2 "आलू" को सभी अर्थों के लिए कह सकते हैं कि संख्या वहन करती है। " आलू -17 " संस्करण में आपका स्वागत है !!

समान संस्करण उन्नत / संगत हैं
यदि मेरे कंप्यूटर पर संस्करण 3.7 है, और 3.8 सभी नए चमकदार फ्रॉज़बॉट्स के साथ आता है, तो मुझे उम्मीद है कि कुछ उन्नयन या पैच के साथ या जो भी हो, मेरा 3.7 बिना किसी रुकावट के 3.8 बन सकता है। लेकिन अगर मैं 3.7 पर हूं और आप 5.2 जारी करते हैं, तो मैं इतना आशावादी नहीं हूं। बेशक, मैं निराश होने के बजाय सुखद आश्चर्यचकित रहूँगा।

पहला अंक महत्वपूर्ण है अगर
मैं इस बात का उल्लेख करने की जहमत नहीं उठाऊंगा तो जावा इस मामले पर प्रमुखता से भ्रमित नहीं होगा। जब तक किसी ने आपको बताया, आप उम्मीद नहीं करेंगे कि "जावा 7" वास्तव में संस्करण 1.7 था। और जब आपने पहली बार यह सुना, तो आप की प्रतिक्रिया लगभग निश्चित थी: " क्या? .. क्यों? "

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

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

EDIT -
मैं इस बात का उल्लेख करना भूल गया, लेकिन कालेब ने इसे अच्छी तरह से बताया: संस्करण संख्या का उपयोग किसी भी महत्वपूर्ण (जैसे स्थिर / अस्थिर) को इंगित करने के लिए न करें अन्यथा इसे स्पष्ट रूप से कहीं और न करें। हां, आप जानते हैं कि विषम लघु संस्करण संख्या विकास को इंगित करता है, लेकिन यह हम में से एक बनाता है। डेबियन की "अस्थिर" रिलीज़ मॉनीकर एक अच्छा उदाहरण है; या आप एक पूरी तरह से अलग उत्पाद का नाम भी इस्तेमाल कर सकते हैं; आपके उत्पाद के नाम के लिए "Frozbot 1.2", और आपके विकास संस्करण के लिए "Devbot 1.3"।

Comments

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

— चमत्कारिक काल

हालांकि यहां अन्य अच्छे उत्तर हैं, मुझे यह सबसे ज्यादा पसंद है, क्योंकि यह बहुत अच्छी तरह से विभिन्न नुकसानों और उपयोग के मामलों की व्याख्या करता है। अंत में हम उपरोक्त टिप्पणी में उल्लिखित अर्थ वर्जनिंग के साथ समझौता कर चुके हैं, जो आपके द्वारा वर्णित के समान है।

— बिट-पाइरेट

Answer 2

एक बार, अस्थिर शाखा को स्थिर माना जाता है, चलो 1.5.3 में कहते हैं, हम इसे 1.4.0 के रूप में जारी करेंगे।

नहीं नहीं। अस्थिर 1.5.3 के लिए स्थिर 1.6.0 से शुरू होना चाहिए (और 1.4.x सिर्फ छूट गया, यदि आप सेमीफाइनल संस्करण का उपयोग करने के लिए wan6t)

Answer 3

आप दो अलग चीजों को इंगित करने के लिए एक मान का उपयोग करने का प्रयास कर रहे हैं।

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

दूसरा, आप इंगित करने का प्रयास कर रहे हैं कि दिया गया संस्करण स्थिर है या नहीं।

यह संभव है एक एकल के साथ दोनों बातों से संकेत मिलता है "संस्करण संख्या," बस के रूप में कुछ दुकानों से संकेत मिलता है कि क्या एक आइटम बिक्री पर है कुछ मूल्य निर्धारण योजना का प्रयोग करेंगे। उदाहरण के लिए, मेरे पास एक दुकान पर '3' में समाप्त होने वाली कीमतें अंतिम बिक्री मूल्य हैं। यह उन कर्मचारियों के लिए अच्छा काम करता है, जो जल्दी से बिक्री मूल्य प्राप्त करना सीखते हैं, लेकिन यह अपने ग्राहकों को बिक्री के बारे में बताने का एक शानदार तरीका नहीं है। इस कारण से, वे बिक्री वस्तुओं के पास भी संकेत देते हैं। आप ऐसा ही कुछ कर सकते हैं, जैसे कि स्थिर रिलीज के लिए कम से कम महत्वपूर्ण अंक बनाना और प्रायोगिक रिलीज के लिए इसे अजीब बनाना। मुझे लगता है, हालांकि, यदि आप कुछ ऐसा जारी करने जा रहे हैं जो प्रायोगिक है, तो आपको इसे स्पष्ट रूप से चिह्नित करना चाहिए। आप संस्करण स्ट्रिंग के आरंभ या अंत में 'X' जोड़ सकते हैं, जैसे:X.1.5.31.5.3.X। आप कर सकते थे यहां तक कि उस के बाद एक प्रायोगिक संस्करण संख्या, ताकि आप सभी एक ही आधार संस्करण के आधार पर कई प्रयोगात्मक संस्करण जारी कर सकता है: 1.5.3.X1, 1.5.3.X2।

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

Comments

+1 शानदार उदाहरण: " मेरे पास एक स्टोर पर '3' में समाप्त होने वाली कीमतें अंतिम बिक्री मूल्य हैं ... लेकिन यह आपके ग्राहकों को बिक्री के बारे में बताने का एक शानदार तरीका नहीं है। "

— tylerl

Answer 4

मैं प्रमुख /minor.patch प्रारूप का उपयोग करने का सुझाव दूंगा, स्थिर / अस्थिर संस्करणों के लिए एक एक्सटेंशन "टैग" का उपयोग करके, और प्रमुख और लघु संख्याओं का एक निश्चित अर्थ:

major.minor.patch-stable|unstable

कहाँ पे

major  only changes if there are incompatible changes in the API
minor  changes if there are changes in the API but backward compatibility is given
patch  any other changes, could be the build number or any other increasing number
-stable indicates the stable version
-unstable indicates the unstable version

इस तरह निर्भरता आसानी से प्रबंधित की जाती है और प्रत्येक घटक क्लाइंट / उपयोगकर्ता को बताएंगे जब उन्हें नए संस्करणों पर अधिक ध्यान देना होगा। उदाहरण के लिए, यदि घटक ए (1.1.0-स्थिर) बी (5.4.534-स्थिर) पर निर्भर करता है और बी का एक नया संस्करण होने वाला है (6.1.0-अस्थिर) तुरंत पता चल जाता है कि ए को बदलना होगा, संभवतः काफी हद तक ।

Answer 5

मुझे वास्तव में पसंद है कि हाइबरनेटिंग गैंडों ने रवेनडब विज़-ए-विज़ संस्करणों का निर्माण किया है - उनके पास बस एक निरंतर निर्माण संख्या है। जब वे एक स्थिर हो जाते हैं तो यह स्थिर हो जाता है। लेकिन सब कुछ एक रिलीज उम्मीदवार है।

Comments

उनके पास बस एक कभी न घटने वाला बिल्ड नंबर है - प्रिय भगवान मुझे उम्मीद है कि वास्तव में आपका मतलब क्या है, यह वास्तव में संस्करण संख्याओं के संदर्भ को बदल देता है अगर वे तेजी से बढ़ते हुए हो जाते हैं।

— tylerl

धिक्कार है आपको स्वतः। । ।

— व्याट बार्नेट