मुझे वर्जन संख्या कब बढ़ानी चाहिए?

23

मैंने स्कूल में प्रोग्रामिंग नहीं सीखी और मैं एक (पेशेवर) डेवलपर के रूप में काम नहीं करता, इसलिए बहुत सारी मूल बातें मेरे लिए बिल्कुल स्पष्ट नहीं हैं। यह सवाल उनमें से एक को स्पष्ट करने की कोशिश करता है।

अब मान लीजिए कि मेरे पास मुद्दे हैं #1, #2और #3मेरे मुद्दे ट्रैकर में जो संस्करण के लिए सही / बढ़ाया जाना तय है 1.0.0और यह अंतिम (स्थिर) संस्करण है 0.9.0।

मुझे वर्जन कब बढ़ाना चाहिए 1.0.0? जब ए) उपरोक्त मुद्दों में से केवल एक सूचीबद्ध है या बंद है) जब संस्करण से संबंधित सभी मुद्दे 1.0बंद हो गए हैं?

इसे करने का सही तरीका कौन सा है ? और सही तरीके से, मेरा मतलब है कि वर्तमान में उद्योग में क्या उपयोग किया जाता है।

versioning semantic-versioning

— अहमद
स्रोत

22

देखें semver.org

— Martijn Pieters

1

और आप अपनी अगली रिलीज में भी तीनों मुद्दों को शामिल कर सकते हैं ।

— मार्टिजन पीटरर्स

हाँ, मैं पहले से ही SemVer और सभी का उपयोग कर रहा तीन मुद्दों अगली फिल्म में होने वाले हैं :)

— अहमद

मैंने भ्रमित होने से बचने के लिए प्रश्न संपादित किया।

— अहमद

14

मैं आपको बता सकता हूं कि मैं इसे काम पर कैसे करता हूं।

हमारे पास एक निरंतर एकीकरण सर्वर है जो एक संस्करण पैकेज का निर्माण, परीक्षण, टैग और आउटपुट करता है। हम केवल अगले चरण के लिए आगे बढ़ते हैं यदि पिछला वाला 100% सफल हो।

हमारा संस्करण इस तरह दिखता है: <मेजर वर्जन>। <माइनर वर्जन> <बिल्ड नंबर>

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

— dietbuddha
स्रोत

लेकिन अगर आपके पास उदाहरण के लिए <Minor Version>, 1.0.0 पर पूरी होने वाली एन्हांसमेंट की श्रृंखला है। क्या आपको यह सब बढ़ाने के लिए "ओके!" कहने में सक्षम होने की आवश्यकता है ? अब यह संस्करण 1.0.0 है "या आप पहली बार एन्हांसमेंट होते ही संस्करण 1.0.0 में वृद्धि करेंगे?"

— अहमद

@ जाहिद ने उस दृष्टिकोण को देखा है जो 1.4.2"इस समय के लिए तैयार है, और कुछ और तैयार है" ... मैंने यह भी देखा है 1.4.2कि "यह इस तारीख को रिलीज होगी जो कुछ भी तैयार है"। यह आपके रिलीज के चक्र पर निर्भर करता है।

5

@ahmed यदि 0.xx से 1.xx तक जाने के मानदंड एक सेट सुविधा / सुधार के पूरा होने के बाद होते हैं, तो मैं केवल इन सभी के पूर्ण होने के बाद वृद्धि करूंगा। नोट: कि हम उस तरह से काम नहीं करते हैं। हम एक संस्करण को लक्षित नहीं करते हैं और तय करते हैं कि इसमें क्या सुधार होते हैं। हम फ़िक्सेस को लक्षित करते हैं। जो संस्करण हमें प्राप्त होता है वह विशुद्ध रूप से ट्रैकिंग और पहचान के लिए होता है न कि एक लक्ष्य के लिए।

— आहारबोधा

यह वास्तव में क्या मैं जानना चाहता था है :)

— अहमद

21

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

— ग्रेग हेविल
स्रोत

क्या यह वेब विकास पर भी लागू होता है जहां एक रिलीज एक मामूली बग के लिए एक साधारण हॉटफ़िक्स हो सकता है?

— अहमद

4

क्या आप हॉटफ़िक्स जारी करने से पहले QA करते हैं? यह एक रिलीज है। यदि पूर्ण उत्पाद का नहीं, तो हॉटफिक्स का।

— पीटर के।

@ahmed ऐसे परिदृश्य में, संस्करण संख्याएं अक्सर उपयोगकर्ता के लिए अदृश्य होती हैं और इस प्रकार अर्थहीन होती हैं (रिलीज संख्या मुख्य रूप से विपणन और तकनीकी सहायता के लिए मौजूद होती है, दोनों कई वेबप के लिए लागू नहीं होती हैं)। बस कमिट आईडी का उपयोग करना पर्याप्त हो सकता है। यदि आप संस्करण संख्याओं का उपयोग करने पर ज़ोर देते हैं, तो हाँ, मैं शायद पैचवेल बढ़ाऊंगा।

— आमोन

मैं यहाँ बहुत सी चीजें सीख रहा हूँ: p तो, इसे योग करने के लिए: मुझे कमिटिंग नंबर की आवश्यकता नहीं है क्योंकि कमिट आईडी पर्याप्त हैं, क्योंकि सभी उपयोगकर्ता वैसे भी अंतिम संस्करण का उपयोग कर रहे होंगे।

— अहमद

2

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

— मटनज़

2

निरंतर रूप से तैनात वेब एप्लिकेशनों के लिए, हम सीवर अप फ्रंट का उपयोग करके बिल्ड नंबर बनाते हैं और एक बिल्ड नंबर टेलिंग करते हैं, अर्थात: 2.5.3.4328 जहां 4328 निरंतर एकीकरण प्रणाली से आता है। सामान्य अपेक्षा यह है कि जानबूझकर किए गए कदमों से संख्या में परिवर्तन होता है लेकिन यह कि बिल्ड संख्या सही यूनिक आईडी है।

ऐसा लगता है कि यहां तैनाती के दिन और संबंधित svn बिल्ड नंबर पर कब्जा कर रहा है:

        <div id="svnrev">
            rev 2013.10.21.1078
        </div>

हांलांकि इसकी कीमत के बारे निश्चित नहीं हूँ।

— व्याट बार्नेट
स्रोत

0

अन्य उत्तर पहले से ही महान हैं, इसलिए मैं केवल उनके ऊपर जोड़ दूंगा। यदि आपका सॉफ़्टवेयर जारी नहीं हुआ है और आपको वास्तव में सार्वजनिक संस्करण (गैर-सार्वजनिक संस्करण आपके VCS है) की आवश्यकता नहीं है, तो अपने संस्करण के अंत में " SNAPSHOT " कीवर्ड जोड़ें । कुछ प्रणालियाँ, विशेष रूप से निर्भरता प्रबंधन में, स्नैपशॉट को रिलीज़ किए गए संस्करणों से अलग तरीके से मानते हैं कि वे संस्करण संख्या के बजाय स्नैपशॉट की परिवर्तन तिथि की तुलना करते हैं। तो अगर आपके पास v। 1.0.0-SNAPSHOT है जो सुबह 8 बजे से एक पैकेज रेपो में है और स्थानीय निर्भरता डाउनलोडर में 7am से एक ही संस्करण है, यह रेपो से अपडेटेड डाउनलोड करता है।

जैसा कि ऊपर कहा गया है, आपके निजी संस्करण को आपके संस्करण नियंत्रण प्रणाली (git, svn आदि) द्वारा प्रदान किया गया है।

— ह्यूबर्ट ग्रेज्सकोविआक
स्रोत

0

यहाँ एक और दृष्टिकोण के संस्करण के सिद्धांत के बारे में पर्याप्त कहा गया है।

मुझे संस्करण 1.0.0 में वृद्धि कब करनी चाहिए?

मैं अपने उत्तर को प्रमुख संस्करण संख्या के परिवर्तन पर केंद्रित करने जा रहा हूँ।

मेरा उत्तर है: मूल रूप से जब आप इसके लिए तैयार हों। 0.9 से 1.0 तक जाना एक बड़ी बात है, क्योंकि सार्वजनिक धारणा यह होगी कि आप बीटा-उत्पाद से आधिकारिक रिलीज़ के लिए जा रहे हैं।

(मैं यहाँ एक कंपनी से एक वाणिज्यिक उत्पाद है) मान जा रहा हूँ।

0.9 से 1.0 तक जाने से पहले कुछ सवाल।

क्या आपके संगठन के पास अपने सभी वर्तमान ग्राहकों को सूचित करने का समय है। पार्टी देना। बहुत सारे समर्थन अनुरोध प्राप्त करें। एक खाता प्रबंधक अपने उत्पाद को बेचने के लिए? आदि आदि।

हां, मैं संस्करण को एक विपणन उपकरण के रूप में देखता हूं और यदि आप अपने चारों ओर देखते हैं तो देखते हैं कि मूल रूप से उद्योग मानक है।

हमारी कंपनी 2.x से 3.0 संस्करण में गई और एक शानदार पार्टी की, बहुत सारी चर्चाएं पैदा कीं और इस वजह से उन्हें कुछ नए ग्राहक मिले। कुछ इंटरफ़ेस अपडेट के अलावा संस्करणों के बीच का अंतर काफी मामूली था।

— पीटर बी
स्रोत