2008-09-25 20 views
21

मैं ऑनलाइन सॉफ्टवेयर वितरित करता हूं, और हमेशा आश्चर्य करता हूं कि संस्करण संख्याओं को बेहतर तरीके से परिभाषित करने का कोई उचित तरीका है या नहीं।सही सॉफ्टवेयर संस्करण संख्या प्राप्त करना। v1.0.0.1

चलिए उत्तर में एबीसीडी मानते हैं। आप प्रत्येक घटक को कब बढ़ाते हैं?

क्या आप किसी भी अन्य संस्करण संख्या चाल का उपयोग करते हैं जैसे कि डी मोड 2 == 1 का मतलब है कि यह केवल घर में रिलीज है?

क्या आपके पास अपने संस्करण संख्याओं के साथ बीटा रिलीज है, या क्या आपके पास प्रति संस्करण संख्या बीटा रिलीज़ है?

+0

पहले से ही चर्चा की: [http://stackoverflow.com/questions/65718/what-do-the-numbers-in-a-version-typically-represent-ie-v1901](http://stackoverflow। कॉम/प्रश्न/65718/क्या-क्या-संख्या-में-संस्करण-आम तौर पर प्रतिनिधित्व-यानी-v1901) – Kev

उत्तर

29

मुझे साल की तरह शुरू हो रहा है। कृपया [.बिल्ड] सम्मेलन कि कुछ ऐप्स (उदा। पर्सफोर्स) का उपयोग करते हैं। असल में यह केवल उस वर्ष में कहता है जिसमें आप रिलीज करते हैं, और उस वर्ष के भीतर अनुक्रम। तो 2008.1 पहला संस्करण होगा, और यदि आपने एक महीने या तीन महीने बाद जारी किया, तो यह 2008.2 पर जाएगा।

इस योजना का लाभ रिलीज की कोई अंतर्निहित "परिमाण" नहीं है, जहां आप इस बारे में तर्क देते हैं कि कोई सुविधा प्रमुख संस्करण वृद्धि के लिए पर्याप्त है या नहीं।

बिल्ड नंबर पर टैग करने के लिए एक वैकल्पिक अतिरिक्त है, लेकिन यह केवल आंतरिक उद्देश्यों के लिए होता है (उदा। EXE/DLL में जोड़ा गया ताकि आप फ़ाइल का निरीक्षण कर सकें और सुनिश्चित कर सकें कि सही निर्माण है)।

+0

मुझे यह विचार पसंद है, इसे साझा करने के लिए धन्यवाद। – robsoft

+1

एक और अच्छी योजना सिर्फ इस प्रारूप में निर्माण तिथि का उपयोग कर रही है: YYYY.MM.DD.BuildNumber, जहां BuildNumber या तो एक निरंतर संख्या (परिवर्तनीय) है या बस प्रत्येक दिन 1 से शुरू होता है। उदाहरण: 2008.03.24.1 या 2008.03.24.14503। – steffenj

+0

यह मुख्य रूप से आंतरिक रिलीज के लिए है, अधिक "सार्वजनिक" रिलीज 2008.03 के रूप में मुद्रित संस्करण देखेंगे यदि आप महीने में एक बार से अधिक बार जारी नहीं करते हैं (या 2008.03a 2008.03b के रूप में ध्वज रखरखाव रिलीज़) और इसी तरह)। – steffenj

1

मैं वी.आर.एम. उदाहरण का उपयोग करता हूं उदा। 2.5.1

वी (संस्करण) परिवर्तन एक प्रमुख पुनर्लेखन
आर (संशोधन) परिवर्तन कर रहे हैं महत्वपूर्ण नई सुविधाओं या बग फिक्स कर रहे हैं
एम (संशोधन) परिवर्तन मामूली बख्श फिक्स (लेखन, आदि) हैं

मैं कभी-कभी अंत में एक एसवीएन प्रतिबद्ध संख्या का भी उपयोग करता हूं।

3

हमारी नीति:

  • ए - महत्वपूर्ण (> 25%) परिवर्तन या कार्यक्षमता या इंटरफ़ेस में जोड़।
  • बी - छोटे बदलाव या कार्यक्षमता में जोड़ या इंटरफ़ेस।
  • सी - मामूली परिवर्तन इंटरफ़ेस तोड़ते हैं।
  • डी - पर फ़िक्स करता है जो इंटरफ़ेस को परिवर्तित नहीं करता है।
+0

ब्रेकिंग परिवर्तन सी में जाते हैं? मुझे लगता है कि आपने यहां बी और सी को बदल दिया है। छोटे बदलाव और जोड़ों से ब्रेकिंग परिवर्तन अधिक महत्वपूर्ण हैं। –

+0

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

2

लोग इसे वास्तव में होने की अपेक्षा अधिक कठिन बनाना चाहते हैं। यदि आपके उत्पाद में केवल एक लंबी अवधि की शाखा है, तो बस अपने निर्माण संख्या द्वारा लगातार संस्करणों का नाम दें। यदि आपके पास कुछ प्रकार का "मामूली बग फिक्स फ्री है, लेकिन आपको प्रमुख नए संस्करणों के लिए भुगतान करना होगा", तो 1.0, 1.1 ... 1.n, 2.0, 2.1 ... आदि

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

+0

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

7

मैं आमतौर पर एक निर्माण काउंटर (संकलक द्वारा स्वत: वेतन वृद्धि) के रूप में डी का उपयोग मैं सी हर बार एक निर्माण करने के लिए "सार्वजनिक" (नहीं हर निर्माण जारी किया गया है) ए और बी प्रमुख/लघु संस्करण के रूप में उपयोग किया जाता है जारी किया गया है बढ़ाने के संख्या और मैन्युअल रूप से बदल दिया।

+0

यहां +1 - यह ठीक है कि मैं इसे कैसे करता हूं। – robsoft

5

मुझे लगता है कि इस प्रश्न का उत्तर देने के दो तरीके हैं, और वे पूरी तरह से मानार्थ नहीं हैं।

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

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

फिर माइक्रोसॉफ़्ट का उदाहरण है, जहां नेट फ्रेमवर्क के लिए संस्करण संख्याओं का एकमात्र तर्कसंगत स्पष्टीकरण यह है कि मार्केटिंग शामिल था।

2

एकमात्र उपयोग जिसे मैंने कभी भी संस्करण संख्या से बनाया है, ताकि ग्राहक मुझे बता सके कि वे संस्करण 2.5.1.0 या जो कुछ भी उपयोग कर रहे हैं।

मेरा एकमात्र नियम उस संख्या की रिपोर्टिंग में गलतियों को कम करने के लिए डिज़ाइन किया गया है: सभी चार संख्याओं को केवल 1 अंक होना चाहिए

1.1.2.3 

ठीक है, लेकिन

1.0.1.23 

नहीं है। ग्राहक दोनों संख्याओं (मौखिक रूप से, कम से कम) "एक-एक-दो-तीन" की रिपोर्ट करने की संभावना रखते हैं। अक्सर

ऑटो incrementing संख्या का निर्माण

1.0.1.12537 

जो वास्तव में मदद नहीं करता है, या तो की तरह संस्करण संख्याओं का परिणाम है।

0

घर के विकास के लिए, हम निम्नलिखित प्रारूप का उपयोग करते हैं।

[Program #] . [Year] . [Month] . [Release # of this app within the month] 

उदाहरण के लिए, अगर मैं आज आवेदन # 15 को रिहा कर रहा हूँ, और यह इस महीने के तीसरे अद्यतन है, तो मेरी संस्करण # हो जाएगा

15.2008.9.3 

यह पूरी तरह से गैर मानक है, लेकिन यह है हमारे लिए उपयोगी

0

पिछले छह प्रमुख संस्करणों के लिए, हमने M.0.m.b का उपयोग किया है जहां एम प्रमुख संस्करण है, एम मामूली संस्करण है, और बी बिल्ड संख्या है। इसलिए जारी संस्करणों में 6.0.2, 7.0.1, ..., 11.0.0 तक शामिल थे। मत पूछें कि दूसरा नंबर हमेशा 0 क्यों है; मैंने कई बार पूछा है और कोई भी वास्तव में जानता है। 1 99 6 में 5.5 जारी किए जाने के बाद से हमारे पास शून्य नहीं था।

2

एक अच्छा और गैर तकनीकी योजना सिर्फ इस प्रारूप में निर्माण की तारीख का उपयोग करता है:

YYYY.MM.DD.BuildNumber

जहां बिल्ड नम्बर या तो एक निरंतर संख्या (परिवर्तनीय) है या बस प्रत्येक दिन 1 से अधिक शुरू होता है।

उदाहरण: 2008.03.24.1 या 2008.03.24.14503

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

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

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

8

मेरी राय में, लगभग किसी भी रिलीज संख्या योजना को कम या ज्यादा कम से कम काम करने के लिए बनाया जा सकता है। जिस प्रणाली पर मैं काम करता हूं वह 11.50.यूसी 3 जैसे संस्करण संख्याओं का उपयोग करता है, जहां यू 32-बिट यूनिक्स इंगित करता है, और सी 3 मामूली संशोधन (फिक्स पैक) संख्या है; अन्य प्लेटफार्म प्रकारों के लिए अन्य अक्षरों का उपयोग किया जाता है। (मैं इस योजना की सिफारिश नहीं करता, लेकिन यह काम करता है।)

कुछ सुनहरे नियम हैं जिन्हें अब तक नहीं बताया गया है, लेकिन जो लोगों ने चर्चा की है, उनमें अंतर्निहित हैं।

  • एक ही संस्करण को दो बार रिलीज़ न करें - एक बार संस्करण 1.0.0 किसी को भी जारी किया जाता है, इसे कभी भी पुनः जारी नहीं किया जा सकता है।
  • रिलीज संख्याओं को एकान्त रूप से बढ़ाना चाहिए। यही है, संस्करण 1.0.1 या 1.1.0 या 2.0.0 में कोड हमेशा संस्करण 1.0.0, 1.0.9, या 1.4.3 (क्रमशः) से बाद में होना चाहिए।

अब, व्यवहार में, लोग पुराने संस्करणों के लिए फिक्स जारी करने के लिए है, जबकि नए संस्करण उपलब्ध हैं की क्या ज़रूरत है - जीसीसी देखते हैं, उदाहरण के लिए:

  • जीसीसी 3.4.6 4.0.0 के बाद जारी किया गया था, 4.1.0 (और AFAICR 4.2.0), लेकिन यह जीसीसी 4.x में जोड़े गए अतिरिक्त विशेषताओं को जोड़ने के बजाय जीसीसी 3.4.x की कार्यक्षमता जारी रखता है।

तो, आपको अपनी संस्करण संख्या योजना को ध्यान से बनाना होगा।

एक अन्य बिंदु है जिस मुझे पूरा विश्वास है में:

  • रिलीज़ संस्करण संख्या मुख्यमंत्री (VCS) सिस्टम संस्करण नंबर से संबंधित नहीं है, तुच्छ कार्यक्रमों के अलावा। एक से अधिक मुख्य स्रोत फ़ाइल वाले सॉफ़्टवेयर का कोई भी गंभीर टुकड़ा किसी एकल फ़ाइल के संस्करण से संबंधित संस्करण संख्या होगा।

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

जिन चीजों के साथ मैं काम करता हूं, उनके लिए संस्करण संख्या पूरी तरह से राजनीतिक निर्णय है।

संयोग से, मुझे सॉफ़्टवेयर पता है जो संस्करण 1.00 से 9.53 तक रिलीज़ के माध्यम से चला गया, लेकिन फिर यह 2.80 हो गया।यह एक सकल गलती थी - मार्केटिंग द्वारा निर्धारित। अनुमोदित, सॉफ़्टवेयर का संस्करण 4.x अप्रचलित है, इसलिए यह तुरंत भ्रम के लिए नहीं बना था, लेकिन सॉफ्टवेयर का संस्करण 5.x अभी भी उपयोग में है और बेचा गया है, और संशोधन पहले ही 3.50 तक पहुंच चुके हैं। मैं बहुत चिंतित हूं कि मेरे कोड को 5.x (पुरानी शैली) और 5.x (नई शैली) दोनों के साथ काम करना है, जब अपरिहार्य संघर्ष होता है। मुझे लगता है कि मुझे आशा है कि वे 5x तक बदलने पर डिलिवरी करेंगे। पुराने 5.x वास्तव में मर चुका है - लेकिन मैं आशावादी नहीं हूं। मैं 3.50 कोड का प्रतिनिधित्व करने के लिए 9.60 जैसे कृत्रिम संस्करण संख्या का भी उपयोग करता हूं, ताकि मैं if VERSION > 900 परीक्षण कर सकूं, ऐसा करने के बजाय: if (VERSION >= 900 || (VERSION >= 280 && VERSION < 400), जहां मैं 9 00 तक संस्करण 9.00 का प्रतिनिधित्व करता हूं। और फिर महत्वपूर्ण बदलाव आया है एरिक रेमंड Software Release Practice HOWTO नामकरण पर (लिंक किए गए) अनुभाग सहित (प्रदान करता है: - संस्करण 3.00.xC3 में मेरी योजना नाबालिग रिहाई के स्तर पर परिवर्तन का पता लगाने के लिए ... भुनभुनाना ... भुनभुनाना ...

नायब विफल रहता है संख्या) रिलीज।

1

यह दिन के अंत में और वास्तव में स्वयं/आपकी टीम तक वास्तव में व्यक्तिपरक है।

बस पहले से ही सभी उत्तरों को देखें - सभी बहुत अलग हैं।

व्यक्तिगत रूप से मैं Major.Minor.*.* का उपयोग करता हूं - जहां विजुअल स्टूडियो स्वचालित रूप से संशोधन/निर्माण संख्या में भर जाता है। इसका उपयोग किया जाता है जहां मैं भी काम करता हूं।

1

एक अच्छा उपयोगकर्ता के अनुकूल संस्करण योजना पर वर्ष मैक ओएस उत्पन्न इस एप्पल तकनीकी नोट में वर्णित है: http://developer.apple.com/technotes/tn/tn1132.html

1

मैं Year.Month.Day पसंद है। तो, v2009.6.8 इस पोस्ट का "संस्करण" होगा। डुप्लिकेट करना असंभव है (तर्कसंगत) और यह बहुत स्पष्ट है जब कुछ नया रिलीज होता है। आप दशमलव को भी छोड़ सकते हैं और इसे v20090608 बना सकते हैं।

1

लाइब्रेरी के मामले में, संस्करण संख्या आपको दो रिलीज़ के बीच संगतता के स्तर के बारे में बताती है, और इस प्रकार अपग्रेड कितना मुश्किल होगा।

एक बग फिक्स रिलीज को बाइनरी, स्रोत और क्रमबद्धता संगतता को संरक्षित करने की आवश्यकता है।

माइनर रिलीज विभिन्न परियोजनाओं के लिए अलग-अलग चीजों का मतलब है, लेकिन आमतौर पर उन्हें स्रोत संगतता को संरक्षित करने की आवश्यकता नहीं होती है।

प्रमुख संस्करण संख्याएं सभी तीन रूपों को तोड़ सकती हैं।

मैंने तर्क here के बारे में और अधिक लिखा।

1

जिथब दुनिया में, यह संस्करण संख्याओं के लिए टॉम प्रेस्टन-वर्नर के "सेमेवर" spec का पालन करने के लिए लोकप्रिय हो गया है।

http://semver.org/ से

:

एक संस्करण संख्या MAJOR.MINOR.PATCH को देखते हुए, तब बढ़ेगी:

प्रमुख संस्करण है जब आप असंगत एपीआई परिवर्तन, लघु संस्करण पड़ता है जब आप एक backwards- में कार्यक्षमता जोड़ने संगत तरीके से, और पैच संस्करण जब आप पीछे-संगत बग फिक्स करते हैं। अतिरिक्त प्री-रिलीज और मेटाडेटा बनाने के लिए लेबल MA12OR.MINOR.PATCH प्रारूप में एक्सटेंशन के रूप में उपलब्ध हैं।