कोड संस्करण परिवर्तन "नियम"

Question

मुझे पता है कि सॉफ्टवेयर संस्करण नियंत्रण के बारे में कोई निश्चित नियम नहीं हैं लेकिन मेरे पास कई प्रश्न हैं।

1) संस्करणों को कैसे अपग्रेड करें सही ढंग से

मैं एक छोटे से सॉफ्टवेयर है कि मैंने कुछ समय पहले शुरू कर दिया है और जब से मैं खरोंच से शुरू कर दिया मैं संस्करण 0.1 के साथ शुरू कर दिया।

जैसा कि मैंने और अधिक कार्यक्षमता जोड़ा है, मैं मामूली संख्या को अपग्रेड कर रहा हूं। अब मैं v0.5.7 (बग फिक्स और मामूली परिवर्तनों के लिए नए कार्यों और संशोधन (.7) के लिए मामूली (.5) में हूं, बात यह है कि कार्यक्रम वितरण के लिए लगभग पूरा हो गया है, लेकिन अब मैं "गायब हूं "कई मामूली संस्करण, आप लोग उस स्थिति को कैसे संभालेंगे? क्या आप बस संख्याओं को कूदते हैं?

जो मुझे दूसरे प्रश्न पर लाता है।

2) एक अच्छा प्रारंभिक संस्करण संख्या

मैं के बारे में एक नई परियोजना शुरू करने के लिए कर रहा हूँ बात है। इस बार एक परियोजना का छोटा नहीं है और यह संशोधित करने के लिए सार्वजनिक और स्वतंत्र होगा, मैं ऊपर उल्लिखित मुद्दों को नहीं देखना चाहता हूं। तो कौन सा अच्छा प्रारंभिक बिंदु होगा?

बोनस सवाल:

3) यह 10 से ऊपर नंबर बनाने के लिए ठीक है? v1.25 या v2.2.30 की तरह?

मैंने इस तरह के नंबरिंग के साथ सॉफ़्टवेयर नहीं देखा है (शायद वे इसे केवल सहायता अनुभाग में या अपने वेब पेज में दिखाते हैं), फिर मुझे पता है कि इसके लिए कोई नियम नहीं है लेकिन ऐसा लगता है कि संस्करण संख्याओं को रखने के तरीके पर एक सामान्य सहमति है।

Answer 1

संस्करण nubering नीतियों बार (।: 11.2.0.1.0
भी देखें Software Versioning is RidiculousVersion numbers and JSR277, या Oracle देखते हैं, अपने Oracle डाटाबेस 11g रिलीज़ 2 के साथ) पर थोड़ा पागल हो सकता है।

लेकिन आप अच्छी शुरुआत के रूप में Eclipse Version Number policy देखकर शुरू कर सकते हैं।
यदि आपको वास्तव में लगता है कि आपको तीन से अधिक अंकों की आवश्यकता है, तो यह V.R.M.F. Maintenance Stream Delivery Vehicle terminology explanation भी दिलचस्प है, लेकिन पोस्ट 1.0 सॉफ़्टवेयर के लिए अधिक, जहां फिक्स पैक और अंतरिम फ़िक्स क्रमशः हैं।

---

1/"यह पहले से ही जहाज": 1.0.0

इसके अलावा "1.oh-oh" संस्करण के रूप में जाना जाता है। कम से कम, यह वहां है और आप प्रतिक्रिया प्राप्त कर सकते हैं और तेज़ को फिर से शुरू कर सकते हैं।

2/0.x यदि प्रमुख विशेषताएं अभी भी अनुपलब्ध हैं; 1.0.0 यदि प्रमुख विशेषताएं हैं।

3/हाँ, पर मैं केवल कई वर्षों में एक उम्र के साथ बड़ी परियोजनाओं के लिए कह सकते हैं कि (एक दशक आमतौर पर)

---

ध्यान दें कि "सही ढंग से" (Semantic Versioning 2.0.0 में लंबाई में वर्णित किया जा रहा है, जबकि) भी कर सकते हैं और अधिक व्यावहारिक कारकों द्वारा निर्देशित किया:

announcement for Git 1.9 (Januaury 2014) देखें:

एक रिलीज उम्मीदवार Git v1.9-rc2 अब सामान्य स्थानों पर परीक्षण के लिए उपलब्ध है।

मैंने सुना है अफवाहें हैं कि विभिन्न तीसरे पक्ष के उपकरणों दो अंकों संस्करण संख्याओं (उदाहरण के लिए "Git 2.0") पसंद नहीं है और barfing छोड़ दिया और सही जब उपयोगकर्ताओं को स्थापित v1.9-RC1 शुरू कर दिया ।
यह उनकी लापरवाही धारणा के लिए उन पर हँसने आकर्षक है, वहीं मैं भी व्यावहारिक हूँ और उनकी मदद करने के आगामी रिलीज v1.9.0 बुला आपत्ति नहीं है।

हम उस मार्ग जाना (और मैं इस पल में उस मार्ग से जाने के लिए इच्छुक हूँ), तो संस्करण स्कीम होगी:

• अगली फिल्म उम्मीदवार v1.9.0-rc3, नहीं v1.9-rc3 हो जाएगा;
• v1.9.0 के लिए पहली रखरखाव रिहाई v1.9.1 हो जाएगा (और वां एक v1.9.N हो); और
• v1.9.0 के बाद फीचर रिलीज या तो v1.10.0 या v2.0.0 होगा, इस पर निर्भर करता है कि फीचर कूद कितनी बड़ी है।

Answer 2

यहां तक ​​कि मैं संस्करण संख्या को परिभाषित करने सीआरएम के साथ विकसित कर रहा है, जबकि के साथ इस समस्या का सामना करना पड़ा, जब से मैं सभी प्रणालियों में एक ही निर्माण को तैनात करना चाहता था। मुझे सिस्टम वैल्यू + मैनुअल + रैंडम्स के साथ इसे हल करने का एक तरीका मिला।

मेजर संस्करण:

एक विधानसभा के लिए संस्करण जानकारी चार मूल्यों के होते हैं। मामूली संस्करण। बिल्ड संख्या। संशोधन

जो डिफ़ॉल्ट रूप से प्रारंभिक संस्करण 1.0.0.0 बनाता है। अधिक समझने के लिए मैं के साथ

TFS रिलीज बदलें। टीएफएस स्प्रिंट। संख्या बदलें।बढ़ी हुईं बिल्ड नंबर

अपने TFS में मान लीजिए कि एक एकल रिलीज 30 स्प्रिंट होते हैं और उसके बाद रिहाई 2 हो जाता है, इसलिए पहले रिहाई के लिए मान होंगे:

TFS रिलीज: 1

वर्तमान स्प्रिंट 4 है, तो TFS स्प्रिंट होगा

TFS स्प्रिंट: 4

अब तीसरा हिस्सा डेवलपर द्वारा प्रबंधित किया जाता है, प्रारंभिक संस्करण के लिए हमारे पास 0 हो सकता है जिसे प्रत्येक ChangeRequest या BugFix के लिए +1 बढ़ाया जा सकता है।

बदलें संख्या: 0 - प्रारंभिक संस्करण का प्रतिनिधित्व संख्या बदलें: 1 - प्रतिनिधित्व परिवर्तन कट्टरपंथी घुड़दौड़ का घोड़ा बदलें r: 2 - प्रतिनिधित्व बग सुधार

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

अंतिम भाग डिफ़ॉल्ट संख्या था, शुक्रिया। नेट हमें डिफ़ॉल्ट बिल्ड नंबर डालने की अनुमति देता है। यह प्रत्येक संकलन/निर्माण के साथ बढ़ता रहता है जो हस्ताक्षर स्टैंप प्रदान करता है, अगर कोई और इसे पुनर्निर्माण करता है।

लागू करना सीखें:

ओपन गुण फ़ोल्डर में AssemblyInfo.cs और AssemblyFileVersion टिप्पणी, इस AssemblyFileVersion & AssemblyVersion ही कर देगा।

// You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below: 
[assembly: AssemblyVersion("1.4.2.*")] 
//[assembly: AssemblyFileVersion("1.0.0.0")] 

तो अंतिम संस्करण के रूप में बाहर आ जाएगा: 1.4.2.4512 या कुछ

इस दृष्टिकोण का लाभ यह है कि आप कार्य है जिसके लिए कोड उत्पन्न होता है ट्रैक कर सकते हैं। बस संस्करण संख्या को देखकर मैं कह सकता हूँ, "अरे स्प्रिंट 4 के लिए और कुछ कोड बदलने के साथ अपनी रिहाई 1

Answer 3

हमारी कंपनी में, हम चार टोकन संस्करण अवधारणा का उपयोग कर रहे हैं यह ABCD तरह की तरह कुछ है।।:

(major).(feature).(revision).(bug/refactoring) 

यह जो हम अपने विकास के जीवन चक्र में इस्तेमाल करते हैं। हम ट्रैक कर सकते हैं क्या एक नज़र में किया या दो निम्नलिखित संस्करणों के बीच बदल गया है मुद्दा प्रकार के साथ संबंधित है। दो निम्नलिखित संस्करण संख्याओं आप संख्या और के प्रकारों की पहचान कर सकते हैं की तुलना करके मुद्दों को पूरा किया गया। अधिक जानकारी के लिए, full documentation is here.