क्या "संस्करण नामकरण सम्मेलन" आप उपयोग करते हैं? [बन्द है]

Question

क्या विभिन्न संस्करणों के नामकरण विभिन्न परियोजनाओं के अनुकूल हैं? आप क्या उपयोग करते हैं और क्यों?

व्यक्तिगत रूप से, मैं हेक्साडेसिमल (जैसे 11BCF) में एक बिल्ड नंबर पसंद करता हूं, इसे बहुत नियमित रूप से बढ़ाया जाना चाहिए। और फिर ग्राहकों के लिए एक साधारण 3 अंक संस्करण संख्या, यानी 1.1.3।

1.2.3 (11BCF) <- Build number, should correspond with a revision in source control
^ ^ ^
| | |
| | +--- Minor bugs, spelling mistakes, etc.
| +----- Minor features, major bug fixes, etc.
+------- Major version, UX changes, file format changes, etc.

Answer 1

मैं खुद को जेफ एटवुड के साथ पूरी तरह से सहमत होने के लिए शायद ही कभी पाता हूं, लेकिन मैं संस्करण संख्या के .NET सम्मेलन की उनकी राय का पालन करता हूं ।

(प्रमुख संस्करण)। (लघु संस्करण)। (संशोधन संख्या)। (बिल्ड संख्या)

अधिक बार नहीं, व्यक्तिगत परियोजनाओं के लिए, मुझे लगता है कि यह ओवरकिल है। कुछ समय जहां मैंने C # में खोज इंजन जैसी पर्याप्त परियोजनाओं पर काम किया है, मैं इस सम्मेलन में फंस गया हूं और इसे प्रभावी रूप से आंतरिक ट्रैकर के रूप में उपयोग करने में सक्षम रहा हूं।

Comments

यह उस पैटर्न का अनुसरण करता है जो मैंने कई परियोजनाओं में सफलतापूर्वक उपयोग किया है, बड़े या छोटे। यह बहुत प्रभावी है।

— luis.espinal

"चेंज नंबर" का संबंध "परिवर्तनक पहचानकर्ता (हैश)" से कैसे होता है? क्या यह हैश, वृद्धिशील या कुछ और का हिस्सा है?

— जैस ब्राउनिंग

@ जेसे, जहां मैं काम करता हूं, हम मर्क्यूरियल का उपयोग करते हैं, और परिवर्तन संख्या से दूर जाते हैं। हम केवल कभी-कभी एकल रिपॉजिटरी से पुश / पुल करते हैं, इसलिए संख्या विशिष्ट चेकआउट के लिए अद्वितीय नहीं है। हमारे पास तब [प्रमुख] [लघु] है। [बदलाव] तदनुसार (हालांकि प्रमुख और मामूली संख्या अक्सर अंतिम संस्करण के बाद से प्रगति के संकेत की तुलना में अधिक विपणन है)।

— वाई हा ली

यदि आप एक .NET संस्करण संरचना पर ToString () कॉल करते हैं तो बिल्ड 3 नंबर होगा, न कि संशोधन। जैसा कि आप इस शक्तियुक्त पटकथा के साथ देख सकते हैं:$version = New-Object System.Version 1, 2, 3, 4; $version.ToString(); $version.Build;

— जोएल मैकबेथ

क्या "बिल्ड नंबर" का अर्थ है कि यह बग फिक्स की तरह सिर्फ मामूली मोड़ है? किसी भी नई कार्यक्षमता को कम से कम अपनी स्वयं की संशोधन संख्या मिलनी चाहिए?

— काइल डेलानी

Answer 2

सिमेंटिक वर्जनिंग ( http://semver.org/ ) यहाँ एक उल्लेख के योग्य है। यह एक संस्करण योजना के लिए, के रूप में एक सार्वजनिक विनिर्देश है [Major].[Minor].[Patch]। इस योजना की प्रेरणा संस्करण संख्या के साथ अर्थ का संचार करना है।

Comments

आश्चर्य यह अधिक प्यार नहीं मिल रहा है।

— मार्क कैनलस

मुझे पार्टी में थोड़ी देर हो गई ... मैंने मूल प्रश्न के 9 महीने बाद यह उत्तर जोड़ा। ;-)

— एम। डुडले

ऐसा लगता है कि यह रुबाइम्स तर्कसंगत संस्करण नीति के समान है जो मैंने नीचे उल्लेख किया है, केवल बेहतर औपचारिक रूप से।

— केन ब्लूम

@MarkCanlas को अधिक प्यार नहीं मिलता है क्योंकि यह विशिष्ट विचारों को एक प्रमुख / मामूली / पैच रिलीज का गठन करता है। यह API के बारे में बात करती है जो थोड़े अजीब है ...

— रुडोल्फ Olah

SemVer का अर्थ है APIs के संस्करण के लिए, न कि उपयोगकर्ता-सामना करने वाले सॉफ़्टवेयर के लिए: "अर्थ वर्ज़निंग MUST का उपयोग करने वाला सॉफ़्टवेयर सार्वजनिक API घोषित करता है।" इसलिए तकनीकी रूप से, आप सार्वजनिक API के बिना SemVer का उपयोग नहीं कर सकते। हालाँकि, उपयोगकर्ता के सामने आने वाले अनुप्रयोगों के संस्करण के लिए सेमीविअर के समान कुछ अपनाने की समझ हो सकती है।

— Ajedi32

Answer 3

मैं इसका उपयोग नहीं करता, लेकिन मैंने देखा है और यह एक दिलचस्प संरचना है:

Year.Month.Day.Build

स्व ने समझाया।

Comments

और आप हमेशा जानते हैं कि आपका कोड कितना ताज़ा है ..! :)

— लिपिस

यह भी Ubuntu के संस्करण संख्याओं के समान है। वे साल की सुबह की परीक्षा करते हैं: 10.04 और 10.10

— ब्रैड कपिट

यह ध्यान देने योग्य है कि यह केवल एक प्रणाली के लिए अच्छी तरह से काम करता है जिसमें या तो संगतता समस्याएं (एक वेबसाइट) नहीं होती हैं, या स्वाभाविक रूप से हमेशा असंगतता (एक ubuntu रिलीज) होती है।

— जकरियन

@jkerian, इसके लिए अनुकूलता क्यों मायने रखती है?

— AviD

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

— जकरियन

Answer 4

मैं रूबीजीम तर्कसंगत संस्करण नीति का उपयोग करने की कोशिश करता हूं जिसमें:

• बाइनरी संगतता टूटने पर मेजर संस्करण संख्या बढ़ जाती है
• नई कार्यक्षमता जोड़े जाने पर मामूली संस्करण संख्या बढ़ जाती है
• बग फिक्स के लिए बिल्ड नंबर बदलता है।

Comments

इसे मूल रूप से सिमेंटिक वर्जनिंग के

— पैट्रिस एम।

@PatriceM। उस लिंक को शेयर करने के लिए धन्यवाद। semver.org मौजूद नहीं था जब मैंने वह उत्तर लिखा था।

— केन ब्लूम

Answer 5

यहाँ संस्करण क्रमांकन के लिए बहुत बारीक-बारीक दृष्टिकोण है:

• N.x.K, जहां Nऔर Kपूर्णांक हैं। उदाहरण: 1.x.0, 5.x.1, 10.x.33। मध्यवर्ती बिल्ड के लिए उपयोग किया जाता है ।
• N.M.K, जहां N, Mऔर Kपूर्णांक हैं। उदाहरण: 1.0.0, 5.3.1, 10.22.33। रिलीज के लिए इस्तेमाल किया ।
• N.x.x, जहां Nपूर्णांक है। उदाहरण: 1.x.x। समर्थन शाखाओं के लिए उपयोग किया जाता है ।
• N.M.x, जहां Nऔर Mपूर्णांक हैं। उदाहरण: 1.0.x। रिलीज शाखाओं के लिए उपयोग किया जाता है ।

यहाँ संस्करण क्रमांकन दृष्टिकोण के सरल चित्रण के लिए चित्र दिया गया है:

PAइसका मतलब पूर्व अल्फा A का मतलब है अल्फा B का मतलब है बीटा AR का मतलब अल्फा रिलीज BR का मतलब बीटा रिहाई RC का मतलब रिलीज उम्मीदवार ST का मतलब स्थिर

ऐसे वर्जन नंबरिंग दृष्टिकोण के लाभ निम्नलिखित हैं:

• यह चुस्त सॉफ्टवेयर विकास जीवन चक्र की बारीकियों का प्रतिनिधित्व करता है ।
• यह स्रोत कोड भंडार संरचना की बारीकियों को ध्यान में रखता है ।
• यह उन लोगों के लिए आत्म व्याख्या है जो पैटर्न के अभ्यस्त थे। हर पैटर्न अलग-अलग कलाकृतियों का प्रतिनिधित्व करता है। इस तरह के पैटर्न को आसानी से पार्स किया जा सकता है और अन्य उद्देश्यों के लिए उपयोग किया जा सकता है, जैसे कि मुद्दा ट्रैकिंग।
• वर्जनिंग पैटर्न सेट किया गया है, जो वर्णित वर्जनिंग एप्रोच के लिए बेसिक मेट्रिक्स इकट्ठा करने और प्लानिंग के लिए इस्तेमाल किया जा सकता है ।
• यह परिपक्वता और गुणवत्ता के स्तर की अवधारणाओं पर केंद्रित है । बहुत बार ऐसे संस्करण संख्याओं को 1.0.0 बहुत आवश्यकता के बिना असाइन किया जाता है (जब सॉफ्टवेयर गहरे अल्फा में होता है)। प्रस्तुत संस्करण क्रमांकन दृष्टिकोण परिपक्वता के कई स्तरों को स्थापित करने की अनुमति देता है। सबसे सरल मामले में इसके केवल दो स्तर होंगे: मध्यवर्ती बिल्ड ( N.x.K) और रिलीज़ ( N.M.K)। रिलीज का मतलब है कि पूर्ण संस्करण संख्या ( N.M.K) के साथ सॉफ्टवेयर का टुकड़ा आपूर्तिकर्ता कंपनी / संगठन / टीम के भीतर किसी प्रकार की गुणवत्ता प्रबंधन प्रक्रिया से गुजरा है।
• यह विकास और परीक्षण दोनों की चुस्त प्रकृति का प्रमाण है ।
• सॉफ्टवेयर संरचना और वास्तुकला के लिए मॉड्यूलर दृष्टिकोण को प्रोत्साहित करता है ।

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

व्यक्तिगत रूप से वास्तविक संस्करण संख्याओं के बजाय दिनांक संस्करण का उपयोग करने के प्रति मेरा दृष्टिकोण मानता है कि सॉफ्टवेयर के डेवलपर्स दिनांकित संस्करणों के साथ:

• सॉफ्टवेयर विकास जीवनचक्र के बारे में कुछ नहीं पता । विकास आमतौर पर चुस्त और चलने का होता है। संस्करण क्रमांकन दृष्टिकोण को सॉफ्टवेयर विकास प्रक्रिया की पुनरावृत्ति प्रकृति का प्रतिनिधित्व करना चाहिए।
• सॉफ्टवेयर की गुणवत्ता की परवाह न करें । गुणवत्ता नियंत्रण और आश्वासन चुस्त और पुनरावृत्त हैं। विकास की तरह। और संस्करण संख्या विकास और गुणवत्ता नियंत्रण / आश्वासन दोनों की चुस्त और पुनरावृत्ति प्रकृति का प्रमाण होना चाहिए।
• वास्तुकला या उनके आवेदन के विचार के बारे में परवाह न करें । मेजर वर्जन नंबर ( Nइन N.M.K) आर्किटेक्चर सॉल्यूशन और एप्लिकेशन के अंतर्निहित सिद्धांत दोनों के लिए जिम्मेदार है। Nवास्तुकला या उसके कार्य / कार्यप्रणाली के प्रमुख विचारों और सिद्धांतों में परिवर्तन के अनुसार प्रमुख संस्करण संख्या को बदलना है।
• उनका कोडबेस पर नियंत्रण नहीं है । शायद केवल एक शाखा (ट्रंक) है और इसका उपयोग हर चीज के लिए किया जाता है। व्यक्तिगत रूप से मुझे नहीं लगता कि यह सही है क्योंकि यह एक बड़े कचरा डंप बनने के लिए कोडबेस को प्रोत्साहित करता है।

यह दृष्टिकोण थोड़ा विवादास्पद लग सकता है, लेकिन मेरा मानना ​​है कि सॉफ्टवेयर को उपयुक्त संस्करण संख्या देने का यह सबसे सरल तरीका है।

Comments

पहला लिंक नीचे ……………

— Pacerier

Answer 6

आपके द्वारा जारी किए जाने वाले प्रत्येक प्रमुख संस्करण के लिए, आंतरिक रूप से कॉल करने वाले कार्य संस्करण के लिए यह असामान्य नहीं है। उदाहरण के लिए, मेरी आखिरी नौकरी में, हमने निम्नलिखित उबंटू-प्रेरित नामकरण सम्मेलन के साथ एक प्रमुख संस्करण का उल्लेख किया:

[बीमारी की स्थिति] [अनुप्रास पशु का नाम]

जिसे " लिम्प लैंप्री ", " वाउन्डेड वॉम्बैट " और " अस्थमैटिक एंटेटर " जैसे नाम दिए गए ।

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

Comments

समय और ऊर्जा के एक अकुशल उपयोग की तरह लगता है .............

— Pacerier

इसलिए वह टिप्पणी छोड़ रहा था, लेकिन उसने आपको रोका नहीं।

— जेसी सी। स्लीकर

यह एक संपूर्ण परिमाण कम है ......

— 15er 15

Answer 7

Generation.Version.Revision.Build (9.99.999.9999)

पीढ़ी शायद ही कभी बदलती है। उत्पाद पर केवल एक बड़ा मोड़: डॉस -> विंडोज, पूर्ण पुनर्रचना।

संस्करण बड़े असंगत परिवर्तन, नई कार्यक्षमता, सॉफ्टवेयर पर कुछ विशिष्ट प्रतिमानों में परिवर्तन आदि के लिए है।

संशोधन अक्सर किया जाता है (छोटी विशेषताओं और बग फिक्स)।

बिल्ड आंतरिक जानकारी है।

Comments

अच्छा विचार। आपको "पीढ़ी" का विचार कहां से मिला?

— पचेरियर Pac

Answer 8

git describeआपके द्वारा चुने गए नंबरिंग कन्वेंशन को एक अच्छा विस्तार प्रदान करता है। अपनी बिल्ड / पैकेजिंग / परिनियोजन प्रक्रिया में इसे एम्बेड करना काफी आसान है।

मान लीजिए कि आप अपने टैग किए गए रिलीज़ संस्करणों को एबीसी (मेजर.मिनोर.मैनेरेस) नाम देते हैं। git describeकिसी दिए गए कमिट पर कमेटी के सबसे हाल के टैग किए गए पूर्वज मिल जाएंगे, उसके बाद से उसके कमिट्स की संख्या, और कमिट के संक्षिप्त SHA1:

1.2.3-164-g6f10c

यदि आप वास्तव में संस्करणों में से एक पर हैं, तो निश्चित रूप से, आपको केवल टैग (1.2.3) मिलेगा।

यह आपको यह बताने का अच्छा लाभ है कि आप वास्तव में किस स्रोत से निर्मित हुए हैं, जबकि प्रत्येक एकल को स्वयं बनाने की संख्या नहीं है।

Answer 9

Major.Minor.Public (बिल्ड) [अल्फा / बीटा / ट्रायल], जैसे "4.08c (1290)"

• मेजर के साथ प्रमुख संस्करण संख्या (1, 2, 3 ...)
• माइनर 2 अंकों का मामूली संस्करण (01, 02, 03 ...) है। आमतौर पर दसियों अंक में वृद्धि होती है जब महत्वपूर्ण नई कार्यक्षमता जोड़ी जाती है, जो बग के लिए ही तय होती है।
• सार्वजनिक निर्माण की सार्वजनिक रिलीज़ (ए, बी, सी, डी, ई), जो कि मामूली संस्करण से अक्सर भिन्न होती है, यदि कोई मामूली संस्करण सार्वजनिक अपडेट के रूप में कभी जारी नहीं होता है
• बिल्ड, वास्तविक बिल्ड नंबर होने के नाते जो संकलक का ध्यान रखता है।
• TRIAL, ALPHA, BETA X, या RC X के साथ उन विशेष मामलों के लिए जोड़ा गया।

Answer 10

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

मैं .NET का उपयोग करता हूं इसलिए मैं .NET संस्करण नंबरिंग सिस्टम के साथ फंस गया हूं, लेकिन मैं संख्याओं के साथ अर्थ अर्थ देने की कोशिश करता हूं

major.minor.build.revision

• प्रमुख = (परियोजना तक)
• मामूली = (परियोजना तक)
• बिल्ड = हडसन से बिल्ड नंबर (आप यहां टीमसिटी या टीमबिल्ड आदि का उपयोग कर सकते हैं)
• संशोधन = तोड़फोड़ या बाजार में संशोधन (परियोजना पर निर्भर करता है और इसका उपयोग क्या है)

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

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

यह सब पता लगाने की क्षमता के बारे में है!

Answer 11

हम Major.Minor.Build # .YYMMDD [प्रत्यय] का उपयोग करते हैं , क्योंकि हम आम तौर पर किसी एक विशेष दिन पर केवल एक उत्पादन का निर्माण करते हैं (लेकिन अगर एक से अधिक है तो ab / c / d प्रत्यय का उपयोग करें) और YYMMDD उपयोगकर्ता / ग्राहक / प्रबंधन देता है निर्माण की आयु का एक संकेत, जहां 6.3.1389 नहीं है।

महत्वपूर्ण उत्पाद सुविधाओं (भुगतान-के लिए) के साथ प्रमुख संख्या बढ़ जाती है।

फिक्स / सुधार (मुफ्त अद्यतन) के साथ मामूली संख्या में वृद्धि।

बिल्ड हमेशा बढ़ता है; सभी जहाज नहीं बनाते हैं, इसलिए यह एक रैखिक प्रगति नहीं है।

Answer 12

संस्करण संख्याओं में पर्याप्त जानकारी होनी चाहिए कि आप गलत रिलीज़ प्रकार की समस्याओं में टकराव और बग को ठीक करने से बचें, लेकिन अतिरिक्त जानकारी नहीं देनी चाहिए जो प्रासंगिक नहीं है।

उदाहरण के लिए यदि आप दिनांक का उपयोग करते हैं तो ग्राहक बता सकते हैं कि उनके पास एक पुराना संस्करण है, और पुराने संस्करणों के विरुद्ध पैच में भ्रामक संस्करण हो सकते हैं।

मुझे व्यक्तिगत रूप से अर्थ वर्जनिंग पसंद है :

• जारी हैं Major। Minor।Patch
• Patch वेतन वृद्धि हर बार जब आप एक बिल्ड जारी करते हैं।
• Minor हर बार वेतन वृद्धि के पीछे संगत कार्यक्षमता जोड़ी जाती है।
• Major वेतन वृद्धि जब नई कार्यक्षमता पीछे संगत नहीं है।
• जब Major== 0 आप अल्फा / प्री-रिलीज़ में हैं। Major> = 1 आपकी सार्वजनिक रिलीज़ हैं।
• जब आप वेतन वृद्धि करते हैं तो हर बार कम संख्या 0 पर रीसेट हो जाती है

  1.5.3-> 1.5.4(बग फिक्स) -> 1.6.0(मामूली विशेषता) -> 2.0.0(परिवर्तन को तोड़ना)

इस तरह यदि कोई उपयोग कर रहा है, तो कहें, संस्करण 1.5.3वे एक नज़र में बता सकते हैं कि वे 1.5.4पैच प्राप्त करने के लिए अपग्रेड कर सकते हैं, यह 1.6.0कार्यक्षमता जोड़ देगा और उन्हें 2.0.0(कम से कम परिवर्तन को संभालने के बिना) अपग्रेड नहीं करना चाहिए ।

Comments

सेमर केवल एपीआई के लिए काम करता है। उत्पाद नहीं।

— पचेरियर

@ स्पेसियर आपको समझा सकता है कि क्यों?

— कीथ

प्रति सेमीवीयर में ही। आप एक सार्वजनिक एपीआई के बिना सेमी वीयर का उपयोग नहीं कर सकते।

— पचेरियर

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

— कीथ

Answer 13

              1.0.0
                |
              1.0.1
                |
(सार्वजनिक 1.0) 1.0.2 -----
                | \
              2.0.0 1.1.0
                | |
              2.0.1 1.1.1 (सार्वजनिक 1.1)
                |
(सार्वजनिक 2.0) 2.0.2 -----
                | \
              3.0.0 2.1.0
                         |
                       2.1.1 (सार्वजनिक 2.1)
                         |
                       2.2.0
                         |
                       2.2.1

X.Y.Zहमारा आंतरिक संस्करण नंबर है। X.Yसार्वजनिक संस्करण संख्या है, हमारे ग्राहकों के लिए एक अर्थ है। जब कोई X.Y.Zसंस्करण सार्वजनिक हो जाता है, तो कभी X.Y.(Z+1)संस्करण नहीं होगा : सार्वजनिक संस्करण हमेशा सीरी का अंतिम होता है।

X जब एक प्रमुख संस्करण जारी किया जाता है तो वृद्धि होती है।

Y बग फिक्स के लिए केवल उन प्रमुख रिलीज की रखरखाव शाखाओं के लिए उपयोग किया जाता है।

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

एक साइड नोट के रूप में, हम releaseसंस्करण संख्या को बढ़ाने के लिए मावेन ( कमांड के साथ ) का उपयोग करते हैं । तो, X.Y.Z-SNAPSHOTसंस्करण भी हैं , (जो किसी भी संस्करण के बीच X.Y.(Z-1)और X.Y.Z) को इंगित करता है ।