वास्तव में MAJOR.MINOR.BUILDNUMBER.REVISION में बिल्ड नंबर क्या है

Question

बिल्ड नंबर्स के बारे में मैं क्या सोचता हूं कि जब भी कोई नया निर्माण होता है, तो एक नया BUILDNUMBER उत्पन्न होता है और उस बिल्ड को सौंपा जाता है। तो मेरे 7.0 संस्करण के आवेदन के लिए रात का निर्माण 7.0.1, 7.0.2 और इसी तरह होगा। ऐसा है क्या? फिर बिल्ड नंबर के बाद REVISION का उपयोग क्या है? या प्रत्येक रात के निर्माण के बाद पुनरावृत्ति भाग को बढ़ाया जा रहा है? मैं यहाँ थोड़ा भ्रमित हूँ ... क्या हम प्रत्येक रात का निर्माण एक BUILD के रूप में करते हैं ?

प्रारूप का उल्लेख यहां किया गया है: असेंबली वर्सन - एमएसडीएन

Comments

तब आप निर्माण संख्या के रूप में तारीख का उपयोग कर सकते थे!

बिल्ड: सिस्टम का प्रत्येक नया निर्माण, संशोधन: किसी रिलीज़ किए गए बिल्ड का हॉटफ़िक्स या "संशोधन", इस प्रकार यह बिल्ड संस्करण को बदल देता है; आप वर्तमान बिल्ड 2.2.12.0 हो सकते हैं, लेकिन रिलीज़ किया गया निर्माण 2.2.8.0 हो सकता है और जब आपको उस हॉटफिक्स की आवश्यकता होती है, तो आप स्रोत कोड को 2.2.8 के लिए खींचते हैं, इसे संशोधित करते हैं और 2.2.8.1, 3 महीने बाद वर्तमान का निर्माण करते हैं 2.2.16.0 लेकिन एक ग्राहक अभी भी 2.2.8.1 पर है और दूसरे बग में चलता है, आप 2.2.8.1 के लिए कोड खींचते हैं और बग को ठीक करने के लिए इसे संशोधित करते हैं, और इसे 2.2.8.2 के रूप में जारी करते हैं

— जिमी हॉफ

Answer 1

मैंने इसे उस रूप में कभी नहीं लिखा है। जहाँ मैं काम करता हूँ, हम MAJOR.MINOR.REVISION.BUILDNUMBER का उपयोग कर रहे हैं, जहाँ MAJOR एक प्रमुख रिलीज़ है (आमतौर पर UI या अंतर्निहित OS में कई नई सुविधाएँ या परिवर्तन), MINOR एक छोटी रिलीज़ (शायद कुछ नई सुविधाएँ) है पिछले प्रमुख रिलीज़, REVISION आमतौर पर पिछली छोटी रिलीज़ (नई कार्यक्षमता नहीं) के लिए एक फिक्स है, और एक नवीनतम संशोधन के निर्माण के लिए BUILDNUMBER वेतन वृद्धि होती है।

उदाहरण के लिए, क्यूए (गुणवत्ता नियंत्रण) के लिए एक संशोधन जारी किया जा सकता है, और वे एक ऐसे मुद्दे के साथ वापस आते हैं जिसमें बदलाव की आवश्यकता होती है। बग को ठीक कर दिया जाएगा, और उसी REVISION नंबर के साथ QA को वापस जारी किया जाएगा, लेकिन एक बढ़ा हुआ BUILDNUMBER।

Comments

+1: यह बहुत ज्यादा है जिस तरह से मैंने इसे हर जगह और भी देखा है। मैंने देखा और पसंद किया है कि कैसे कुछ कंपनियां सिर्फ BUILDNUMBER के लिए डेटटाइम स्टैम्प का उपयोग करती हैं।

— स्टीवन एवर्स

+1: "MAJOR.MINOR.REVISION.BUILDNUMBER" फ़ॉर्म समझ में आता है और समझ में आता है। मैंने MSDN साइट पर BUILDNUMBER.REVISION फ़ॉर्म देखा (लिंक अपडेट किया गया) और इसने मुझे पूरी तरह से भ्रमित कर दिया।

— a9S6

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

— इजाकाता

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

— tcrosley

@tcrosley मुझे लगता है कि यह अस्पष्ट शब्दावली का मामला है। मैं संस्करण नियंत्रण में संशोधन के बारे में सोच रहा था।

— इजाकाता

Answer 2

संपूर्ण भ्रम विभिन्न शब्दार्थों से उपजा है जो एमएस "बिल्ड नंबर" और विशेष रूप से "संशोधन" के लिए उपयोग करता है। शर्तों का मतलब सिर्फ अलग-अलग चीजों से है।

ज्यादातर लोग (स्वयं शामिल) एक सिमेंटिक वर्जन नंबरिंग स्कीम का उपयोग करते हैं, जहां आपको जब भी किसी कारण से एक नया निर्माण करना होता है तो आपको एक उच्च बीआईआईएलडी नंबर मिलता है। हमारे लिए, एक हॉटफिक्स को केवल एक और कोड परिवर्तन माना जाता है, और प्रत्येक सीआई रन के साथ BUILD भाग स्वचालित रूप से बढ़ जाता है। समान MAJ.MIN.REV वाले मॉड्यूल को विनिमेय माना जाता है, और BUILD आपको बताता है कि सबसे हाल ही में कौन सा है।

फिर भी, वृद्धि का संकेत एक नई स्थायी रिलीज शाखा को दर्शाता है, इसीलिए हम इसे BUILD से पहले रखते हैं। उस दृष्टिकोण का नकारात्मक पक्ष यह है कि हमें घटनाओं का निम्नलिखित क्रम मिल सकता है:

• प्रतिबद्ध संख्या 4711: ऐलिस ने फीचर ए जोड़ा
• CI 1.2.3.100 बिल्ड बनाता है
• प्रतिबद्ध संख्या 4712: बॉब संशोधित सुविधा बी
• प्रतिबद्ध संख्या 4713: ऐलिस फिक्स्ड फ़ीचर ए ("हॉटफ़िक्स")
• CI 1.2.3.101 बिल्ड बनाता है

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

MS दोनों शब्दों का अलग-अलग उपयोग करता है। BUILD संख्या स्वचालित रूप से बढ़ाई नहीं जाती है, इसके बजाय इसे कोड की एक विशेष संस्करण के लिए उपयोग किए जाने वाले कोड को फ्रीज करने के लिए एक रिलीज शाखा की तरह माना जा सकता है। समीक्षा उस BUILD शाखा पर लागू अतिरिक्त "गर्म" परिवर्तनों को इंगित करता है। इसलिए अनुक्रम निम्नानुसार होगा:

• प्रतिबद्ध संख्या 4711: ऐलिस ने ट्रंक / मास्टर को एक फीचर जोड़ा
• कार्ल बिल्ड ब्रांच बनाता है 1.2.100
• CI 1.2.100.0 का निर्माण करता है
• प्रतिबद्ध संख्या 4712: ट्रंक / मास्टर में बॉब संशोधित फीचर बी
• प्रतिबद्ध संख्या 4713: एलिस ने 1.2.100शाखा में सुविधा ए को तय किया
• CI 1.2.100.1 बिल्ड बनाता है

संदर्भ शब्द का उल्लेख हो सकता है

• एक उत्पाद संशोधन (कि ज्यादातर लोग इसका उपयोग कैसे करते हैं)
• एक विशेष दैनिक निर्माण का संशोधन (कि एमएस क्या करता है)

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

हमारे मामले में CI टूल एक रिपॉजिटरी टैग बनाता है, इसलिए हमारे पास आवश्यक होने पर उपयोग करने के लिए हमेशा आवश्यक जानकारी होती है। एसवीएन के साथ यह और भी सरल हो जाता है, क्योंकि टैग और शाखाएं बिल्कुल उसी तरह से लागू की जाती हैं - एक टैग के तहत स्थित शाखा से ज्यादा कुछ नहीं है /tags।

यह सभी देखें

TFS शाखा रणनीति में अक्सर पूछे जाने वाले प्रश्न अनुभाग से :

मुझे पी 1 (हॉटफ़िक्स) टिकट किस शाखा में तय करना चाहिए?

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

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

एक और अच्छा पढ़ा TFS शाखा गाइड है

Comments

यह एक महान जवाब है! +1

— लंकिमार्ट

Answer 3

Microsoft Versionवर्ग के लिए अपने MSDN प्रलेखन में .NET संस्करण संख्या के प्रत्येक घटक के उद्देश्य का वर्णन करता है । यहाँ प्रासंगिक हिस्सा है:

MAJOR.MINOR [.build [.revision]]

घटकों का उपयोग सम्मेलन द्वारा निम्नानुसार किया जाता है:

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

माइनर: यदि दो विधानसभाओं पर नाम और प्रमुख संस्करण संख्या समान हैं, लेकिन मामूली संस्करण संख्या भिन्न है, तो यह पिछड़ी संगतता के इरादे से महत्वपूर्ण वृद्धि को इंगित करता है। यह उच्चतर लघु संस्करण संख्या किसी उत्पाद के एक बिंदु विमोचन या किसी उत्पाद के पूर्ण रूप से पिछड़े-संगत नए संस्करण का संकेत दे सकती है।

बिल्ड: बिल्ड नंबर में अंतर उसी स्रोत के पुनर्संयोजन का प्रतिनिधित्व करता है। प्रोसेसर, प्लेटफ़ॉर्म, या कंपाइलर बदलने पर विभिन्न बिल्ड नंबरों का उपयोग किया जा सकता है।

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

http://msdn.microsoft.com/en-us/library/system.version.aspx

Comments

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

— जिमी हॉफ़ा

एक जवाब के लिए +1 जिसमें एक उचित निर्माण संख्या है। यदि संख्या संशोधन समान रहती है (जब तक कि आपके पास एक पागल निर्माण प्रणाली नहीं है जो समय पर निर्भर है) तो संख्या में वृद्धि करना बेकार है। संकलक, प्लेटफार्मों, आदि का संकेत करने के लिए बिल्ड नंबर का उपयोग करना उपयोगी है।

— थॉमस ईडिंग

Buildएक के रूप में recompilation of the same sourceएक महत्वपूर्ण मुद्दा यह है कि याद किया जाता है हो रहा है। यदि यह एक कोड परिवर्तन है (जिसमें एक पूरी नई मेजर / माइनर वृद्धि की आवश्यकता नहीं है) तो Revisionउसे भी बदलना होगा।

— पीटरएक्स

@PeterX पुन: लक्ष्यीकरण के दौरान निर्माण-विशिष्ट परिवर्तनों के मामले में?

— Samis

Answer 4

कम से कम कुछ अलग चीजें हैं जो मैं निर्माण संख्या को संदर्भित करने की कल्पना कर सकता हूं:

1. स्रोत नियंत्रण संस्करण जो जारी किया गया था। उदाहरण के लिए यदि संशोधन # 12345 जारी किया गया था, तो इसे बिल्ड नंबर होने के द्वारा ट्रैक किया जा सकता है और यदि इसे पैच किया जाता है, तो यह संशोधित हो सकता है, क्योंकि यह नई कार्यक्षमता नहीं है जो प्रमुख या मामूली संस्करणों को बढ़ाएगा। और बिल्ड नंबर को उस स्थिति में याद रखना होगा जब कोई उस बिल्ड को फिर से चलाना चाहता है।

2. सतत एकीकरण सर्वर पहचानकर्ता। इस स्थिति में, CI सर्वर प्रत्येक बिल्ड को रन कर सकता है और इस प्रकार बिल्ड नंबर एक सफल बिल्ड हो जाता है और इस परिदृश्य में रिविजन पार्ट की आवश्यकता नहीं होती है।

ऐसे अन्य भी हो सकते हैं जिन्हें मैं नहीं जानता, लेकिन ये बड़े हैं जिन्हें मैं जानता हूं कि कोड बेस पर संख्याओं की बात आती है।

Comments

# 1 के लिए +1। मुझे स्रोत नियंत्रण संशोधन # का उपयोग करना पसंद है, क्योंकि यह स्रोत नियंत्रण में उस संस्करण के खिलाफ रिपोर्ट किए गए बग को देखना आसान बनाता है।

— मेसन व्हीलर

@MasonWheeler: यदि आप SVN पर हैं तो बहुत अच्छा काम करता है। लेकिन जब आप dcvs की जमीन पर पहुंचते हैं तो यह पूरी तरह से हो जाता है। यह एक बात होगी जो मुझे सबसे ज्यादा याद आती है कि मैं svn को कैसे जोड़ूंगा।

— व्याट बार्नेट

Answer 5

एक बिल्ड नंबर आमतौर पर हर बिल्ड में बढ़ जाता है इसलिए यह अद्वितीय होता है।

सादगी के लिए, जब भी MAJOR या MINOR नंबर टकरा जाते हैं, तो कुछ बिल्ड नंबर को रीसेट कर देते हैं।

अधिकांश निरंतर एकीकरण इंजन ऑटोजेनरेटेड अद्वितीय बिल्ड नंबरों के लिए अनुमति देते हैं।

Answer 6

संशोधन का उपयोग बिल्डरों के पैच के लिए किया जा सकता है। बता दें कि एक उत्पाद पर 2 टीमें काम करती हैं।

टीम 1 प्रमुख विकास टीम है और निम्न संस्करण स्कीमा 1.0.X.0 के साथ रात का निर्माण करती है, जहां एक्स बढ़ाई जाती है। अब वे 1.0.50.0 पर हैं। टीम 2 समय-समय पर निर्माण कर रही है। मान लें कि वे पिछले सप्ताह से बिल्ड लेते हैं जो 1.0.43.0 है और इसका उपयोग करना शुरू करें। जब टीम 2 को 1.0.43.0 में कोई समस्या मिलती है, तो टीम 1 1.0.51.0 को अग्रिम करती है।

अब टीम 1 उस बिल्ड (43) को ले जाएगी, समस्या को ठीक कर देगी और बिल्ड 2 को 1.0.43.1 के साथ टीम 2 प्रदान करेगी। मुख्य बिल्ड में फिक्स को भी प्रचारित किया जा सकता है, इसलिए यह परिवर्तन 1.0.52.0 में दिखाई देगा।

आशा है कि यह स्पष्ट और सहायक है।

* संशोधन उपयोगी है जब परियोजना में शामिल सभी लोग एक ही बिल्ड का उपयोग नहीं करते हैं और आपको विशिष्ट बिल्ड पैच करने की आवश्यकता होती है।

Answer 7

मुझे सिर्फ यह कहना है कि मैं इसे कैसे देखता हूं और इसका उपयोग करता हूं ...।

प्रोग्रामनाम संस्करण major.minor.build.revision

मेजर: मेरे लिए वर्तमान प्रोजेक्ट मैं काम कर रहा हूं। जब तक मैं एक ही कार्यक्रम के नाम की एक नई परियोजना शुरू नहीं करता तब तक संख्या नहीं बदलेगी। इसका मतलब है कि मैं सचमुच एक ही लिंग का एक नया कार्यक्रम लिख रहा हूं (उदाहरण: एक्सेस v1 - एक्सेस वी -2 - एक्सेस वी -3 * सभी एक ही कार्यक्रम लेकिन पूरी तरह से फिर से लिखा गया)।

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

बिल्ड: यह मैं प्रकाशित मेजर.इनर संस्करण में बहुत छोटे बदलावों को इंगित करने के लिए उपयोग करता हूं। यह लेआउट, रंग योजना आदि में बदलाव हो सकता है।

संशोधन: यह मैं वर्तमान प्रकाशित मेजर में एक बग फिक्स को इंगित करने के लिए उपयोग करता हूं। minor.build - ऐसे अवसर हैं जहां मैं वर्तमान परियोजना की प्रगति नहीं कर रहा हूं और बग उत्पन्न होता है। इस बग को ठीक करने और प्रकाशित करने की आवश्यकता है। इसका मतलब सिर्फ इतना है कि मैं ठीक कर रहा हूं जो मैंने पहले से ही ठीक से काम करने के लिए प्रकाशित किया था। अगर मैं एक नए बिल्ड, एक नए जोड़ पर काम कर रहा हूं या एक नया प्रमुख संस्करण शुरू कर रहा हूं तो मैं भी इसका उपयोग करूंगा। प्रकाशित संस्करण को स्पष्ट रूप से पैच करने की आवश्यकता है जब हम अगले प्रमुख, लघु या निर्माण रिलीज की प्रतीक्षा कर रहे हैं।

तो इस तरह से एक तैयार या रुकी हुई परियोजना को अभी भी तय किया जा सकता है और अगली रिलीज होने तक प्रकाशित किया जा सकता है।

मुझे उम्मीद है कि यह किसी को इस तरह की वर्जनिंग (या काम करने) की बेहतर समझ देगा। मेरे लिए यह एकमात्र परिभाषा और अभ्यास है जो इस प्रकार के संस्करण का उपयोग करते समय किसी भी प्रकार का वास्तविक अर्थ बनाता है।

Answer 8

मैंने केवल रिलीज़ आईडी में अंतिम नंबर के रूप में एक बिल्ड नंबर देखा है। मुझे यकीन नहीं है कि आप बिल्ड नंबर में संशोधन कैसे करेंगे। मुझे लगता है कि अगर आपने कुछ गैर-निर्मित संसाधनों (आइकन, डीबी स्क्रिप्ट, आदि) को बदल दिया है, तो हो सकता है, लेकिन मैंने हाल ही में जिन परियोजनाओं पर काम किया है, उन सभी में संस्करण नियंत्रण के तहत सामान भी है, इसलिए निर्माण प्रक्रिया उन्हें उठाती है जब इंस्टॉलर / रिलीज कर रहा है। मुझे टाइम-स्टैम्प्ड बिल्ड संख्याएँ पसंद हैं, हालाँकि @David के रूप में काफी वर्णन नहीं है (मुझे प्रमुख .minor.revision.HHMM) पसंद है। हालांकि, जहां मैं काम करता हूं, हम बस एक अनुक्रमिक संख्या का उपयोग करते हैं जो हमारा बिल्ड सर्वर उत्पन्न करता है।

Answer 9

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

Answer 10

यह जो कुछ भी तुम चाहते हो वह है। मैं अपने प्रमुख के लिए year.month.day.hhmm का उपयोग करता हूं। अगर मैं एक मिनट से अधिक का उत्पादन कर रहा हूं, तो कुछ गलत है। आप बस एक साधारण वेतन वृद्धि का उपयोग कर सकते हैं, या मैंने उनके लिए कुछ विस्तृत जनरेटर देखे हैं। तुम क्या चाहते हो। उन्हें ऐसा करने की आवश्यकता है ताकि आप उस आउटपुट को बनाने के लिए उपयोग किए जाने वाले स्रोत को प्राप्त कर सकें, इसलिए जो कुछ भी आपको ऐसा करने में सक्षम बनाता है।

Answer 11

अंतिम दो अंक कुल बिल्ड नंबर हैं

1.01.2.1234

बिल्ड नंबर 2.1234 है, हालांकि ज्यादातर लोग 1234 का उपयोग करेंगे क्योंकि 2 भाग अक्सर नहीं बदलते हैं।

Comments

ओपी पूछ रहा है कि बिल्ड नंबर क्या है, न कि संशोधन आईडी में बिल्ड नंबर क्या है।

— कियमलुनो

Answer 12

हमारी टीम तीसरे नंबर (रिविजन) का उपयोग सबवर्सन रिपॉजिटरी के रिवीजन नंबर के रूप में करती है। हम चौथे नंबर (बिल्ड) का उपयोग हमारे टीमसिटी निरंतर एकीकरण सर्वर से बिल्ड नंबर के रूप में करते हैं जो वास्तव में बिल्ड बनाता है। टीमकाइट बिल्ड प्रक्रिया के दौरान इसमें दाईं ओर # एस के साथ एक नई असेंबलीइन्फो फाइल बनाता है।