किस संस्करण संख्या योजना का उपयोग करने के लिए?

मैं एक संस्करण संख्या योजना की तलाश में हूं जो परिवर्तन की सीमा को व्यक्त करता है, विशेष रूप से compatiblity।किस संस्करण संख्या योजना का उपयोग करने के लिए?

<major>.<minor>.<patch>-<qualifier>-<build number> 
example: 4.5.11-RC1-3732

Maven वर्ज़निंग योजना कहाँ परिभाषित किया गया है:

Apache APR, उदाहरण के लिए, अच्छी तरह से ज्ञात संस्करण नंबर योजना

<major>.<minor>.<patch> 
example: 4.5.11

Maven एक समान है, लेकिन और अधिक विस्तृत स्कीमा पता चलता है का उपयोग करें? क्या क्वालीफायर और बिल्ड नंबर के लिए सम्मेलन हैं? शायद मेवेन का उपयोग करना एक बुरा विचार है लेकिन मेवेन संस्करण योजना का पालन न करें ...

आपको अन्य संस्करण संख्या योजनाएं क्या हैं? आप कौन सी योजना पसंद करेंगे और क्यों?

स्रोत

2010-01-12 deamon

http://stackoverflow.com/questions/1889615/version-numbering-basics मदद चाहेंगे? – VonC

यहां current Maven version comparison algorithm और discussion है। जब तक संस्करण केवल बढ़ते हैं, और बिल्ड नंबर को छोड़कर सभी फ़ील्ड मैन्युअल रूप से अपडेट किए जाते हैं, तो आप अच्छे होते हैं। क्वालीफायर इस तरह काम करते हैं: यदि कोई दूसरे का उपसर्ग है, तो पुराना लंबा है। अन्यथा वे वर्णानुक्रम से तुलना की जाती हैं। प्री-रिलीज के लिए उनका इस्तेमाल करें।

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

स्रोत

2010-01-12 11:27:55 Tobu

मैं अर्थपूर्ण संस्करण मानक की अनुशंसा करता हूं, जो मेवेन संस्करण प्रणाली का भी पालन करता है। कृपया संक्षेप में

http://semver.org/

, बाहर की जाँच यह <major>.<minor>.<patch><anything_else> है, और आप के लिए फिट लगता है के रूप में आप कुछ और हिस्सा करने के लिए अतिरिक्त नियम जोड़ सकते हैं। जैसे। -<qualifier>-<build_number>।

स्रोत

2010-01-12 11:37:37 sixohsix

- - मेवेन से योजना बिल्कुल semver.org अनुशंसा से मेल नहीं खाती है। semver.org: "पैच संस्करण ** के तुरंत बाद एक मनमानी स्ट्रिंग ** जोड़कर एक विशेष संस्करण संख्या को इंगित किया जा सकता है। स्ट्रिंग में केवल अल्फान्यूमेरिक्स प्लस डैश [0-9 ए-जेए-जेड-] और ** शामिल होना चाहिए अल्फा चरित्र [ए-ज़ा-जेड] ** से शुरू होना चाहिए। " – deamon

@deamon semver.org शायद इसे साल पहले बदल चुका है लेकिन रिकॉर्ड के लिए अब यह मेवेन स्कीम का अनुपालन करता है: "एक प्री-रिलीज संस्करण पैच संस्करण के तुरंत बाद एक हाइफ़न और डॉट अलग पहचानकर्ताओं की एक श्रृंखला को जोड़कर दर्शाया जा सकता है। पहचानकर्ता केवल एएससीआईआई अल्फान्यूमेरिक्स और हाइफ़न [0-9 ए-जेए-जेड-] शामिल होना चाहिए। पहचानकर्ता खाली नहीं होना चाहिए। संख्यात्मक पहचानकर्ताओं में अग्रणी शून्य शामिल नहीं होना चाहिए। " – Kapep

@ कपाप: प्रारूप अभी भी पूरी तरह से संगत नहीं हैं, क्योंकि तुलनात्मक तुलना एल्गोरिदम सेमेवर बहुत जटिल है कि मैवेन क्या उपयोग करता है। लेकिन अगर आप सिर्फ "-आरसी 1", "-आरसी 2" या इसी तरह से चिपके रहते हैं, तो आपको ठीक होना चाहिए। – sleske

/प्रश्नोत्तर/पूछे जाने वाले प्रश्न/पुस्तकों में कई लेख को पढ़ने के बाद मैं (वर्ज़निंग स्कीमा में सोचने के लिए को कि [प्रमुख]। [माइनर]। [REV] सबसे अधिक उपयोगी संस्करण स्कीमा है परियोजना संस्करण के बीच अनुकूलता का वर्णन बन डेवलपर के लिए , मार्केटिंग के लिए नहीं है)।

प्रमुख परिवर्तन पिछड़े संगत नहीं है और फ़ाइलों, GUIDs, आदि

माइनर परिवर्तन करने के लिए परियोजना का नाम, पथ को बदलने की आवश्यकता होती है पिछड़े संगत है। नई सुविधाओं का परिचय चिह्नित करें।

सुरक्षा/बग फिक्स के लिए आरईवी। पीछे और आगे संगत।

इस संस्करण libtool वर्ज़निंग अर्थ विज्ञान से प्रेरित स्कीमा और लेख से:

http://www106.pair.com/rhp/parallel.html

नोट: मैं भी निर्माण/दिनांक/कस्टम/गुणवत्ता के रूप में अतिरिक्त जानकारी प्रदान करने की सलाह देते हैं ( निर्माण संख्या, निर्माण तिथि, ग्राहक का नाम, रिलीज गुणवत्ता):

हैलो ऐप v2.6.34 नेशनल बैंक के लिए, 2011-05-03, बीटा, निर्माण

लेकिन इस जानकारी नहीं जानकारी वर्ज़निंग है!

स्रोत

2011-10-11 18:24:00 gavenkoa

पूर्णता के लिए शुद्ध रूप से, मैं old Apple standard for version numbers का उल्लेख करूंगा। यह प्रमुख संस्करण जैसा दिखता है। मामूली संस्करण। बग संस्करण। चरण। गैर-रिलीज संशोधन। स्टेज एक कोड सेट घ (विकास), एक (अल्फा), ख (बीटा), या एफसी से तैयार है (अंतिम ग्राहक जहाज - लगभग समान ही रिलीज उम्मीदवार के रूप में, मुझे लगता है) ।

चरण और गैर-रिलीज संशोधन केवल उचित रिलीज के संस्करणों के लिए उपयोग किया जाता है।

तो, कुछ का पहला संस्करण 1.0.0 हो सकता है। आपने 1.0.1 के रूप में एक बगफिक्स जारी किया होगा, एक नया संस्करण (अधिक सुविधाओं के साथ) 1.1 के रूप में, और 2.0 के रूप में एक पुनर्लेख या प्रमुख अपग्रेड जारी किया होगा। यदि आप 2.0.1 की ओर काम करना चाहते हैं, तो आप 2.0.1d1, 2.0.1d2 से 2.0.1d153 पर या जो भी लेते हैं, उसके साथ शुरू कर सकते हैं, फिर 2.0.1 ए 1 को क्यूए में भेजें, और 2.0.1a37 को अनुमोदित करने के बाद , 2.0.1b1 को कुछ इच्छुक पंटर्स को भेजें, फिर 2.0.1b9 फ़ील्ड में एक हफ्ते तक जीवित रहने के बाद 2.0.1 एफसी 1 जलाएं और साइनऑफ प्राप्त करना शुरू करें। जब 2.0.1 एफसी 17 पर्याप्त हो गया, तो यह 2.0.1 बन जाएगा, और बहुत खुशी होगी।

इस प्रारूप को मानकीकृत किया गया था कि इसके लिए एक पैक बाइनरी प्रारूप था, और तुलना करने के लिए पुस्तकालयों में सहायक दिनचर्या।

स्रोत

2012-04-27 16:09:34

पूर्णता पूर्णता (:-)) के लिए, मैं यह इंगित करना चाहता हूं कि आईएमएचओ को प्रत्येक चरण (जो इस योजना का तात्पर्य है) के लिए अलग-अलग निर्माण की आवश्यकता है, यह एक अच्छा विचार नहीं है। कम से कम अंतिम क्यूए/परीक्षण के लिए निर्माण अपरिवर्तित उत्पादन में काम करना चाहिए। व्यवहार में किसी भी आवश्यक अंतर विन्यास के माध्यम से इंजेक्शन किया जाना चाहिए। उदाहरण देखें [अलग 'डीबग' और 'रिलीज' बनाता है?] (Http://stackoverflow.com/questions/420343/separate-debug-and-release-builds)। – sleske

@sleske मुझे नहीं लगता कि यह प्रत्येक चरण के लिए अलग-अलग निर्माण करता है। यदि आप बीटा-परीक्षण चरण में हैं, तो आप देव में 1.2.3 बी 4 बनाएंगे, सीआई के माध्यम से, इसे स्वीकृति देने के लिए क्यूए प्राप्त करें, यूएटी करें, फिर बीटा-टेस्टर्स को इसे उसी बाइनरी का उपयोग करके रोल करें। इसके बजाय, इसका अर्थ यह है कि किसी भी समय, आप जानते हैं कि एक बिल्ड कितना दूर जा सकता है - इसलिए आप जानते हैं कि जब आप प्रतिबद्ध करते हैं तो इसका उपयोग केवल विकास में किया जाएगा, बीटा टेस्टर्स को भेजा जाएगा, जारी किया जाएगा। संक्रमण में कुछ डुप्लिकेशंस है , उदाहरण के लिए यदि 1.2.3 बी 10 बीटा परीक्षण पास करता है, तो वही कोड 1.2.3 एफसी 1 बन जाएगा, जो आदर्श नहीं है। –

ध्यान दें कि एक संस्करण संख्या योजना (जैसे x.y.0 बनाम x.y) बाहरी कारकों से बाधित हो सकती है।

पर विचार करें कि announcement for Git 1.9 (Januaury 2014):

एक रिलीज उम्मीदवार Git v1.9-rc2 अब सामान्य स्थानों पर परीक्षण के लिए उपलब्ध है।

मैंने सुना है अफवाहें हैं कि विभिन्न तीसरे पक्ष के उपकरणों दो अंकों संस्करण संख्याओं (उदाहरण के लिए "Git 2.0") पसंद नहीं है और barfing छोड़ दिया और सही जब उपयोगकर्ताओं को स्थापित v1.9-RC1 शुरू कर दिया ।
हालांकि, यह उनके बेवकूफ धारणा के लिए उन पर हंसने के लिए मोहक है, लेकिन मैं भी व्यावहारिक हूं और उनकी मदद के लिए आने वाली रिलीज v1.9.0 को कॉल करने पर ध्यान न दें।

हम उस मार्ग जाना (और मैं इस पल में उस मार्ग से जाने के लिए इच्छुक हूँ), तो संस्करण स्कीम होगी:

अगली फिल्म उम्मीदवार v1.9.0-rc3, नहीं v1.9-rc3 हो जाएगा;

v1.9.0 के लिए पहली रखरखाव रिलीज v1.9.1 (और एनएच v1.9.N होगा); और

v1.9.0 के बाद फीचर रिलीज या तो v1.10.0 या v2.0.0 होगा, इस पर निर्भर करता है कि फीचर कूद कितनी बड़ी है।

स्रोत

2014-02-04 07:30:33 VonC

किस संस्करण संख्या योजना का उपयोग करने के लिए?

उत्तर

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