क्या VCS में सॉफ़्टवेयर संस्करण संख्याओं को संग्रहीत करना अच्छा है?

एक उत्पाद संस्करण, जैसे कि v1.0.0.100, न केवल सॉफ़्टवेयर का एक अद्वितीय उत्पादन रिलीज़ दर्शाता है, बल्कि उक्त उत्पाद के लिए फ़ीचर सेट और हॉटफ़िक्स चरणों की पहचान करने में मदद करता है। अभी मुझे किसी उत्पाद के अंतिम पैकेज / बिल्ड / बाइनरी संस्करण को बनाए रखने के दो तरीके दिखाई देते हैं:

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

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

दूसरे दृष्टिकोण के साथ समस्या सामंजस्य है। जब आप 1 साल पहले किसी रिलीज़ पर वापस जाते हैं, तो आप पूरी तरह से टैग जानकारी पर भरोसा करेंगे कि इसकी रिलीज़ संख्या की पहचान करें।

दोनों मामलों में, संस्करण संख्या के कुछ पहलू हो सकते हैं जो सीआई बिल्ड से पहले ज्ञात नहीं हैं। उदाहरण के लिए, एक CI बिल्ड प्रोग्रामेटिक रूप से 4 वें कंपोनेंट में डाल सकता है जो वास्तव में ऑटोमेटेड बिल्ड नंबर है (जैसे ब्रांच पर 140 वां बिल्ड)। यह वीसीएस में एक संशोधन संख्या भी हो सकती है।

सॉफ़्टवेयर के संस्करण नंबर के साथ बनाए रखने का सबसे अच्छा तरीका क्या है? क्या "ज्ञात" भागों को हमेशा वीसीएस में बनाए रखा जाना चाहिए? और यदि हां, तो मुख्य शाखाओं में संघर्ष एक मुद्दा है?

अभी हम सीआई बिल्ड प्लान (एटलसियन बैंबू) में निर्दिष्ट और बनाए गए मापदंडों के माध्यम से अपना संस्करण संख्या बनाए रखते हैं। हमें अपनी masterशाखा में विलय करने से पहले सावधान रहना होगा कि CI बिल्ड किकिंग से पहले वर्जन नंबर ठीक से सेटअप हो । Gitflow वर्कफ़्लो के संबंध में, मुझे लगता है कि यदि संस्करण संख्या को स्रोत नियंत्रण में ट्रैक किया गया था, तो हम गारंटी दे सकते हैं कि जब हम releaseरिलीज की तैयारी में अपनी शाखा बनाते हैं तो यह ठीक से सेटअप हो । QA इस शाखा पर अंतिम एकीकरण / धुएं / प्रतिगमन परीक्षण का प्रदर्शन करेगा और साइनऑफ़ पर, एक विलय होने वाला masterहै जो जारी करने की प्रतिबद्धता का संकेत देता है।

— void.pointer
स्रोत

क्या किसी फ़ाइल के दो संस्करणों के बीच एक मर्ज संघर्ष version.txtहोता है, जिसमें एक संस्करण में एकल रेखा होती है 1.0.7और दूसरी 1.2.0वास्तव में हल करने के लिए कठिन होती है? अगर यह दो शाखाओं को मिलाने में एकमात्र संघर्ष है, जो अलग हो गया, तो मैं खुद को बहुत भाग्यशाली समझूंगा। यह कितनी बार होता है? यदि ऐसा होता है, तो क्या यह अच्छी बात नहीं है कि आप सोचने पर मजबूर हो जाएं कि मर्ज किए गए संस्करण की संख्या क्या होनी चाहिए? (शब्द "संस्करण" के अस्पष्ट उपयोग के लिए क्षमा करें।)

— 5gon12eder

@ 5gon12eder मर्ज के बारे में कठिनाइयाँ या भावनाएँ अप्रासंगिक हैं। यह समग्र समाधान का सिर्फ एक नकारात्मक पहलू है।

— void.pointer

जवाबों:

व्यक्तिगत रूप से, मैं विकल्प 3 का चयन करता हूं: वीसीएस मेटाडेटा , विशेष रूप से, टैग में संस्करण संबंधी जानकारी रखें ।

Git ऐसा करना बहुत आसान बनाता है, क्योंकि एक कमांड है git describe, जो एक टैग के आधार पर विशिष्ट रूप से एक प्रतिबद्ध वर्णन कर सकता है। यहां देखिए यह कैसे काम करता है:

यदि वर्तमान प्रतिबद्ध को टैग किया गया है, तो टैग का नाम आउटपुट करें।
अन्यथा, इतिहास को पीछे की ओर तब तक चलाएं जब तक आपको एक टैग नहीं मिल जाता है और फिर निम्नलिखित प्रारूप में एक विवरण आउटपुट करता है <tag>-<number of commits since the tag>-g<abbreviated commit hash>:।
यदि वर्कट्री में अप्रयुक्त परिवर्तन हैं, तो संलग्न करें -dirty।

इसलिए, यदि आप एक रिलीज़ बिल्ड कर रहे हैं, और कमिट किया हुआ है 1.2.3, तो यह आउटपुट होगा 1.2.3। यदि आप वर्तमान में 1.2.4 पर काम कर रहे हैं और आपने 1.2.3 के बाद से 4 कमिट किए हैं, और पेड़ में परिवर्तन नहीं किए हैं, तो यह आउटपुट होगा 1.2.3-4-gdeadbee-dirty।

यह अद्वितीय और नीरस होने की गारंटी है, साथ ही साथ मानव-पठनीय है, और इस प्रकार सीधे संस्करण स्ट्रिंग के रूप में उपयोग किया जा सकता है । आपको केवल यह सुनिश्चित करना है कि टैग के लिए एक उचित नामकरण सम्मेलन हो।

— जॉर्ग डब्ल्यू मित्तग
स्रोत

मैं वास्तव में इस विचार से प्यार करता हूं, लेकिन यह JIRA + बांस के साथ प्रबंधन करना मुश्किल लगता है। बांस केवल शाखाओं पर कार्य करता है, टैग नहीं, इसलिए आपको यह सुनिश्चित करना होगा कि एक निर्माण से पहले एक टैग को धक्का दिया जाए। यह एरर प्रोन है।

— void.pointer

git describeशाखाओं के साथ भी काम करता है: " --all - केवल एनोटेट टैग का उपयोग करने के बजाय, refs/नामस्थान में पाए गए किसी भी रेफ का उपयोग करें । यह विकल्प किसी भी ज्ञात शाखा, रिमोट-ट्रैकिंग शाखा या हल्के टैग से मेल खाता है।" हालांकि यह सुनिश्चित नहीं है कि यह बांस के साथ कैसे काम करता है। (यह निश्चित रूप से शाखाओं के सावधानीपूर्वक नामकरण की आवश्यकता होगी, जैसे सामान्य मोड टैग के साथ करता है।)

— जर्ग डब्ल्यू मित्तग

मैं कुछ लोगों को जानता हूं जो गिट से पूरी तरह से स्वचालित रिलीज करते हैं। संस्करण स्ट्रिंग द्वारा बनाया गया है git describe, चेंजलॉग से उत्पन्न होता है git shortlog(ठीक है, वास्तव में एक स्क्रिप्ट से जो आउटपुट को पार्स करता है git log --pretty=tformat:<some custom format string>), और रिलीज़ नोट्स टैग विवरण से उत्पन्न होते हैं और git notesमहत्वपूर्ण मील के पत्थर से जुड़े होते हैं।

— जोर्ग डब्ल्यू मित्तग

मेरा कहना है, कि टैग को रिलीज से पहले बनाना होगा ताकि आधार नंबर के साथ ठीक से संस्करण होने के बाद यह शुरू हो सके। यह रिलीज के समय या उसके दौरान टैगिंग के सिद्धांत के खिलाफ जाता है । बांस उठाता है (स्वचालित रूप से , मैं gitflow का उपयोग कर रहा हूँ याद से ) के आधार पर बनाता है । अगर कोई बिना टैग के किसी मर्ज को धक्का दे तो क्या होगा ? यह उचित संस्करण का उपयोग नहीं करेगा (वास्तव में यह अंतिम रिलीज के संस्करण का उपयोग करेगा )masterdevelopmaster

— void.pointer

आप इस तरह से एक योजना का उपयोग करते हैं, टैगिंग है रिहा। आह, मुझे लगता है कि तुम क्या देख रहे हो, मुझे लगता है। तो, वर्तमान में, आपका CI सर्वर रिलीज़ ड्राइवर है, और इस परिवर्तन के साथ, SCM रिलीज़ ड्राइवर है, लेकिन आप चाहेंगे कि वह इसी तरह बना रहे?

— जोर्ग डब्ल्यू मित्तग

हाँ। संस्करण संख्या के अधिकांश को vcs में रखना अच्छा अभ्यास है। यदि हम शब्दार्थ संस्करण semver.org पर विचार करते हैं, जहाँ हमारे पास major.minor.patch.build पहले तीनों vcs में रहना चाहिए। अंतिम आपके बिल्ड सर्वर से एक वृद्धि संख्या हो सकती है जिसका उपयोग किसी विशिष्ट बाइनरी को वापस करने के लिए किया जाता है।

.NET में इसे सुविधाजनक बनाने के लिए हमने एक छोटी सी cmd लाइन एक्सई बनाई है जो कि git के लिए प्रतिबद्ध है। प्री-बिल्ड इवेंट के साथ, यह बिल्ड नंबर को चुनता है जिसे बिल्ड के दौरान टीमसिटी ने टैग किया था। यह cmd लाइन टूल ऑटो एक ऐसा वर्ग बनाता है जिसमें एक बिल्ड नंबर होता है। बाकी संस्करण संख्या: major.minor.patch किसी अन्य फ़ाइल में केवल एक सामान्य स्थिरांक है। ये दो साझा फाइलें हर विधानसभा में एक लिंक (alt + shift-drag) के रूप में एक समाधान में शामिल हैं।

यह दृष्टिकोण इतना शक्तिशाली है कि हम टीम कोड का निर्माण और परीक्षण कर सकते हैं। पुश करने के लिए और kudu है इसे फिर से बनाएँ, लेकिन टीम बिल्ड नंबर के साथ dll के संस्करण के रूप में।

— एसेन स्कोव पेडरसन
स्रोत