सी # संशोधन संख्या का प्रबंधन करने के लिए प्रभावी तरीका

Question

सी # 2008 एसपी 1

मुझे आश्चर्य है कि संशोधन संख्या को संभालने का सबसे अच्छा तरीका क्या है।

मैंने हमेशा सोचा था कि आमतौर पर केवल 3 संख्या होती है। (मेजर, माइनर, और बग फिक्स)।

हालांकि, मुझे आश्चर्य है कि बिल्ड नंबर क्या है और संशोधन संख्या क्या है।

उदाहरण के लिए, अतीत में मैंने आमतौर पर केवल 3 संख्याओं का उपयोग किया है। मैं कुछ मामूली परिवर्तन या एक बग फिक्स है मैं तीसरे नंबर (बग फिक्स) में वृद्धि होगी।

क्योंकि मैं इसके लिए नया हूं। पेशेवर दुनिया में आम तौर पर क्या किया जाता है?

किसी भी सलाह के लिए बहुत धन्यवाद,

मेरी AssemblyInfo फ़ाइल में मैं निम्नलिखित है:

// Version information for an assembly consists of the following four values: 
// 
//  Major Version 
//  Minor Version 
//  Build Number 
//  Revision 
// 
// You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below: 
// [assembly: AssemblyVersion("1.0.*")] 
[assembly: AssemblyVersion("1.0.2.*")] 
[assembly: AssemblyFileVersion("1.0.0.0")] 

// 1.0.2 Added feature for detecting if a sound card is installed. 

Answer 1

आपके सभी सुझावों के लिए धन्यवाद।

मैंने निम्नलिखित का उपयोग करने का निर्णय लिया है।

मेरे प्रोजेक्ट में निम्न संस्करण संख्या है: 1.0.2.20। 1.: बड़े बदलाव 0.: माइनर परिवर्तन 2.: बग सुधार 20: सबवर्सन संशोधन संख्या

तो मैं

[assembly: AssemblyVersion("1.0.2.20")] 

कोई सुझाव पर मेरे assemblyinfo.c फ़ाइल में निम्न को बदल दिया है यह विचार, मुझे सुनकर खुशी होगी।

बहुत धन्यवाद,

Answer 2

आज़माएं:

http://autobuildversion.codeplex.com/

Answer 3

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

हमारे Assembly Versioning नीति पर और पढ़ें।

Answer 4

MSDN से:

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

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

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

एफडब्ल्यूआईडब्ल्यू प्रत्येक .NET प्रोजेक्ट में मैंने "X.Y. *" द्वारा शासित किया है। हम बड़े और नाबालिगों को मैन्युअल रूप से नियंत्रित करना चाहते हैं लेकिन सिस्टम को निर्माण और संशोधन को नियंत्रित करने दें।

Answer 5

हम दो की वृद्धि में बग-फ़िक्स नंबर का उपयोग करते हैं। विषम संख्याओं का मतलब मामूली बग फिक्स जारी किया गया है और यहां तक ​​कि संख्याओं का मतलब बग फिक्स पर काम करना है। जाहिर है यह कुछ व्यवसायों में आम है, यानी, मैं जिस में हूं।

विचार आकस्मिक रिलीज की पहचान करना है, और किसी भी तरह से मुझे यह विचार पसंद है। चीजें करना ताकि आप आसानी से चीजें देख सकें जो गलत हैं। यह नहीं कहता कि एक विषम संख्या अनिवार्य रूप से एक गैर-आकस्मिक रिलीज है, केवल इतना है कि यह काफी उच्च संभावना के साथ है।

Answer 6

मुझे लगता है कि पॉल सिकंदर के जवाब सही एक है, लेकिन मैं अपने AssemblyInfo फ़ाइल में निम्न टिप्पणी जोड़ना चाहते हैं:

आप 1.0.2.* याद पिछले बिट (* द्वारा प्रतिस्थापित) एक यादृच्छिक है कि का उपयोग करते हैं संख्या तो अगर आप 1.0.2. * `शाम को बनाते हैं, और कल आप इसे फिर से बनाते हैं, तो दूसरे संस्करण में आपके द्वारा पहले किए गए निर्माण की तुलना में कम संस्करण संख्या हो सकती है।