अपने सॉफ़्टवेयर रिलीज़ को नाम देने के लिए आपकी पसंदीदा विधि क्या है? तरह माइक्रोसॉफ्ट: अल्फा - बीटा - अंतिम - सर्विस पैक ... गूगल की तरह: जीमेल बीटा - बीटा - बीटा - बीटा - :) कुछ सॉफ्टवेयर की तरह: 0.2 - 0.3 - 0.9999 ...अपने सॉफ़्टवेयर रिलीज़ को नाम देने के लिए आपकी पसंदीदा विधि क्या है?
Major.Minor.Release.Build
रिलीज और बिल्ड वृद्धि में "ब्रेकिंग चेंज" नहीं होना चाहिए (उदाहरण के लिए दस्तावेजों को स्टोर करने के लिए एक अलग फ़ाइल प्रारूप है), मुझे पूरा यकीन नहीं है कि मामूली रिलीज की अनुमति है या नहीं।
अल्फा के अर्थ, बीटा प्रत्यय मेरे लिए कर रहे हैं:
अल्फा/पूर्वावलोकन: अरे, मैं कुछ है कि मैं दिखाना चाहता हूँ मिल गया।
बीटा: सुविधा सेट अब तक पूरा हो गया है, लेकिन कुछ बग बाकी हैं।
रिलीज उम्मीदवार: मुझे लगता है कि कोई भी (प्रमुख) बग शेष नहीं है।
अंतिम: अभी भी बग हो सकता है, लेकिन मुझे किसी बिंदु पर रिलीज़ करना होगा ;-)।
मैं पसंद प्रोटोटाइप, अल्फा, बीटा, जीए विधि। यह मुझे उपयोगकर्ताओं/ग्राहकों को सॉफ़्टवेयर की वर्तमान स्थिति को संवाद करने की अनुमति देता है। इसके साथ में मैं संस्करण संख्या प्रदान करता हूं .2, .3, .4।
हम अपने ग्राहकों को अल्फा/बीटा सॉफ्टवेयर जारी नहीं करते हैं। इसलिए हम बस का उपयोग करें:
(जहां एक्स, वाई = 1,2, ...)
छोटे सॉफ्टवेयर के लिए बस मेजर.माइनर। यदि प्रमुख परिवर्तन - कुछ इनपुट फ़ाइलें पिछले संस्करण के साथ संगत नहीं है। हम ग्राहकों को प्रीरलेज़िंग सॉफ्टवेयर नहीं कर रहे हैं, वही संस्करण परीक्षण के लिए और अंतिम रिलीज के लिए है।
माइक्रोसॉफ्ट संस्करण संख्या के साथ-साथ अल्फा, बीटा, जीए monikers का उपयोग करता है।
मुझे लगता है कि संस्करण नामकरण जो आप पूरा करने की कोशिश कर रहे हैं उस पर बहुत निर्भर करता है। यदि आप खपत के लिए कुछ जारी कर रहे हैं और बीटा अवधि से डेटा एकत्र करने की कोशिश नहीं कर रहे हैं, तो इसे बीटा मत कहें। यदि आप तकनीक का पूर्वावलोकन करने की कोशिश नहीं कर रहे हैं, तो इसे अल्फा कॉल न करें।
मैं वर्तमान में वर्तमान में वेब ऐप्स के साथ काम करता हूं, और जब हम तैनात करते हैं तो हम केवल हमारे संस्करणों को बढ़ते पूर्णांक के रूप में देखते हैं (1, 2, 3, 4, 5, आदि)।जटिल नामकरण तर्क में शामिल होने का कोई कारण नहीं है यदि कोई भी संस्करणों की परवाह नहीं करता है।
जिस तरह से हम अपने रिलीज नामकरण कर रहे हैं वह आम तौर पर चरण संख्या है। सरकारी परियोजनाओं के हमारे अनुबंधों में से अधिकांश के साथ हम पहली रिलीज जारी करेंगे और फिर चरण 2, चरण 3, चरण 4 का प्रदर्शन करेंगे क्योंकि इकाई नए फीचर अनुरोधों के साथ आगे बढ़ने का फैसला करती है (और भविष्य के विकास के लिए वित्त पोषण प्राप्त करती है)।
कुछ ओपन सोर्स सॉफ्टवेयर प्रोजेक्ट नाम रिलीज़ होने की तारीख के बाद रिलीज़ होते हैं। उदाहरण के लिए अप्रैल 2008 में उबंटू 8.04 जारी किया गया था और उबंटू 6.06 जून 2006 में जारी किया गया था। लेकिन उबंटू एकमात्र लिनक्स वितरण नहीं है जो इस विधि का उपयोग करता है।
बेशक प्रत्येक उबंटू रिलीज में एक कोड नाम भी होता है जो हर बार एक अलग जानवर होता है, जो एक अलंकृत विशेषण के साथ संयुक्त होता है (विशेषण भी अंदरूनी के लिए एक cutesy shorthand के रूप में कार्य करता है)। प्रत्येक रिलीज वर्णमाला में बढ़ जाती है ताकि लोग आसानी से याद रख सकें कि स्थिर स्ट्रीम में रिलीज कहां रखा जाए। उदाहरण के लिए:
उदाहरण के लिए 6.06, व्यवसायिक ड्रेक 6.10, नुकीला ईएफ़टी 7.04, Feisty फौन 7.10, साहसी गिब्बन
मैं लिनक्स कर्नेल अंकन पसंद करते हैं: major.minor.release.build, लेकिन मैं शायद ही कभी .build भाग का उपयोग करें, और मैं स्थिर/विकास नाबालिगों के लिए भी/विषम संख्याओं का उपयोग नहीं करता हूं।