सॉफ़्टवेयर संस्करण संख्या के रूप में दिनांक

Question

सॉफ़्टवेयर डेवलपर आमतौर पर संस्करण संख्या के रूप में दिनांक का उपयोग नहीं करते हैं, हालांकि YYYYMMDD प्रारूप (या इसके संस्करण) उपयोग करने के लिए पर्याप्त ठोस लगते हैं। क्या उस योजना में कुछ गड़बड़ है? या यह केवल सॉफ्टवेयर के सीमित 'प्रकार' पर लागू होता है (जैसे इन-हाउस प्रोडक्शंस)?

Comments

कुछ मामलों में यह ठीक हो सकता है, लेकिन यह योजना अच्छी तरह से शाखाओं या पुराने कोड को नहीं संभालती है। इस उत्तर की टिप्पणियों पर एक नज़र डालें ।

— मिकमिक

क्या आपका मतलब विंडोज 95 या एमएस ऑफिस 2010 की तरह है?

— मौविसीयल

यदि आपका लक्ष्य एक ही दिन में बनाए गए दो संस्करणों को रोकना है, तो यह ऐसा करेगा।

— जेएफओ

@JeffO HHmmSS को जोड़ने से प्रति दिन कई रिलीज की अनुमति मिल सकती है।

— स्टुपरयूजर

अक्सर कई प्रमुख संस्करणों को समानांतर में बनाए रखा जाता है, मूल रूप से क्योंकि नई सुविधाएँ नए कीड़े लाती हैं। क्या 2012.01 2011.11 की तुलना में बेहतर है, या क्या यह आपके दीर्घकालिक-समर्थन 2003.06 लाइन का एक सुरक्षा पैच संस्करण है?

— स्टीव

Answer 1

यह कुछ ऐसा है जिसे आपको कुछ अलग-अलग कोणों से देखना होगा क्योंकि आपको उपयोगकर्ता की जरूरतों के साथ-साथ सॉफ्टवेयर और डेवलपर्स की जरूरतों को भी ध्यान में रखना होगा।

सामान्य तौर पर, आपके ग्राहक इस बात की बहुत परवाह नहीं करते हैं कि सॉफ़्टवेयर की संस्करण संख्या क्या है जब तक वे जानते हैं कि वे कुछ नया चला रहे हैं (यानी उत्पाद 2012 उत्पाद 2010 की तुलना में नया है) और वे इसे जानते हैं आज तक है अगर वहाँ पैच है कि तैनात किया जा सकता है (यानी उत्पाद 2012, अद्यतन 10)। जैसे, एक ग्राहक ब्रांडिंग स्टैंड पॉइंट से मैं या तो एक जारी रिलीज (जैसे विंडोज एक्सपी, विंडोज विस्टा) को पसंद करता हूं, उसके बाद उपयोगकर्ताओं द्वारा स्थापित किए जाने वाले पैच की सख्त अनुक्रम संख्या हो सकती है।

हालांकि यह कहा गया है कि सॉफ्टवेयर लिखना, जो उन चीजों की जांच करता है जो उपयोगकर्ता के लिए आसान हैं, हुड के तहत कोड को लिखने के लिए बहुत कठिन बना देता है। इस प्रकार मैं सरल Major.Minorसंस्करण योजना को प्राथमिकता देता हूं यदि केवल इसलिए कि आप यह देखने के लिए एक साधारण संख्या की तुलना कर सकते हैं कि कुछ देखने के लिए निम्नलिखित की तरह तारीख तक है:

// Check to see if we can handle the file version
if (this.Version < fileVersion) {
   throw new UnsupportedFileException("The file version is " + fileVersion.toString() + " which is not supported");
}
// Do stuff ...

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

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

Comments

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

— NotMe

Answer 2

किसी तिथि का उपयोग करने में समस्या यह है कि जब यह कारण होता है, तो तारीखों के बजाय विनिर्देशों को गिनती संख्या के विरुद्ध लिखा जाता है।

"कार्यक्षमता का यह टुकड़ा रिलीज़ 1 में होने के कारण है। कार्यक्षमता का दूसरा टुकड़ा रिलीज़ 2 में होने के कारण है।"

आप ऐनक में तारीख का उल्लेख नहीं कर सकते, क्योंकि रिलीज़ की तारीख छूट सकती है।

यदि आपके पास ऐसी औपचारिक प्रक्रिया नहीं है, जो पहले से पहचानी गई विभिन्न रिलीज़ की आवश्यकता है, तो दिनांक का उपयोग करना ठीक है; आपको मिश्रण में दूसरा नंबर जोड़ने की आवश्यकता नहीं है।

संस्करण संख्याओं में दिनांक शामिल होने की संभावना नहीं है, क्योंकि उनका संदर्भ चश्मे से जुड़ा हुआ है।
बिल्ड नंबरों में दिनांक शामिल होने की संभावना है, क्योंकि उनका संदर्भ बिल्ड बनाने के समय से जुड़ा हुआ है।

Comments

मेरा तर्क है कि सुविधाएँ अक्सर एक रिलीज़ से दूसरे में धकेल दी जाती हैं और इसलिए ग्राहक को दिया गया कोई भी डॉक्यूमेंटेशन जो "फीचर x रिलीज़ 2 में होगा" उसी तरह असफलता के लिए बर्बाद है।

— NotMe

@ChrisLively बिल्कुल। सट्टा दस्तावेज़ीकरण और "जैसी भाषा" होने के बजाय "होने की उम्मीद" बहुत दर्दनाक हो सकता है। एक अच्छा उत्पाद स्वामी सही उम्मीदों और योजना को वास्तविक रूप से निर्धारित करेगा।

— स्टुपरयूसर

@NotMe राइट। एक विनिर्देश जो समय से कुछ हफ़्ते पहले संस्करण और रिलीज़ संख्या की योजना बनाता है, वह मूल रूप से गलत है, जब तक कि आप तब तक रिलीज़ में देरी नहीं करना चाहते जब तक कि आपके द्वारा वांछित सुविधाएँ पूरी नहीं हो जातीं। लेकिन वर्तमान प्रवृत्ति अक्सर जारी करना है, अधिमानतः एक नियमित समय पर, जिसका अर्थ है कि आपको कम ही पता है कि कौन से फीचर मौजूद हैं।

— जूल्स

Answer 3

हालाँकि इस दृष्टिकोण के आपके द्वारा बताए गए लाभ हैं, लेकिन अगर आप संस्करण संख्या के रूप में दिनांक का उपयोग करते हैं तो कुछ कमियां हैं:

• दिनांक आधारित संस्करण सपाट हैं। V2.1.3 के साथ आप संस्करण संख्या, उप-संस्करण संख्या और उप-उप-संस्करण संख्या देख सकते हैं। 20110119 के साथ आप केवल तभी देख सकते हैं जब यह लिखा गया था। आप अपने दिनांक-आधारित संस्करणों को महीने तक समूहित कर सकते हैं , लेकिन यह अभी भी आपको कुछ नहीं बताएगा। आपके पास छोटे बग फिक्सिंग के कई धीमे महीने हो सकते हैं और फिर दो सप्ताह की भारी कोडिंग हो सकती है जिसके परिणामस्वरूप एक बड़ी रिलीज होगी। तिथियां आपको यह नहीं बताती हैं कि, नियमित संस्करण संख्याएं हैं।

• यदि आपको वास्तव में दैनिक आधार पर संस्करण को बदलने की आवश्यकता है और संभवतः रिलीज़ संख्या यह इंगित कर सकती है कि आपके पास उचित रिलीज़ प्रक्रिया नहीं है, लेकिन इसके बजाय हर कोई बेतहाशा सामान बदलता है और जब चाहे तब उत्पादन सर्वरों को बढ़ावा देता है। यदि ऐसा है, तो आपको प्रक्रिया में कोई समस्या है, और विभिन्न संस्करण संख्या स्कीमा का उपयोग करने से इसे हल नहीं किया जा सकता है।

Comments

एक दिन में कई रिलीज़ होने से रिलीज़ समस्या होने के बराबर नहीं है। यह क्या संकेत दे सकता है कि आपके पास एक बड़ी परियोजना है, जहां कई लोग / समूह लगातार अपडेट जारी करने के लिए काम कर रहे हैं। ये सुधार या बस एन्हांसमेंट हो सकते हैं।

— NotMe

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

— NotMe

Answer 4

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

दूसरी ओर, 1.0 से 1.1 तक का अपग्रेड, एक मामूली अपग्रेड है और सिद्धांत में मामूली, वृद्धिशील परिवर्तन और बग फिक्स करता है।

यह एक तारीख प्रारूप में प्रस्तुत करना मुश्किल होगा, हालांकि आप मिश्रण का उपयोग कर सकते हैं। उदाहरण के लिए, v1.0.YYYY.MMDD

Comments

बस देखो कि कैसे मोज़िला ने हाल ही में संस्करण संख्या के अपने हैंडलिंग को बदल दिया है। हमेशा के लिए घूमने के लिए इस्तेमाल किए जाने वाले प्रमुख संस्करण संख्या, अब ऐसा लगता है कि हर कुछ महीनों में एक नया प्रमुख संस्करण है। क्यों? - जब वे प्रमुख संस्करण संख्या को टक्कर नहीं देते थे, तो बहुत से लोग वास्तव में विश्वास नहीं करते थे कि कोई नई सुविधाएँ हैं।

— स्टीव

हाँ क्रोम में एक विचित्र संस्करण योजना भी है - मुझे लगता है कि वे एक या दो साल में मुद्दों को हिट करेंगे जब वे संस्करण 21474836478.0 जारी कर रहे हैं। (ठीक है, मैं थोड़ा अतिरंजित करता हूं लेकिन वे बेवकूफ-संख्या बिंदु को अंततः मार देंगे)।

— जॉनएल

@ जॉन: मुझे विश्वास नहीं है कि औसत क्रोम उपयोगकर्ता परवाह करता है कि वह किस प्रमुख संस्करण में है। एप्लिकेशन स्वचालित रूप से खुद को अपडेट करता है और "लगता है" वही रहता है भले ही बहुत सारे बदलाव किए गए हों।

— Spoike

@ सपाई: सच। मैं मुख्य रूप से परवाह करता हूं क्योंकि मैं Secunia PSI का उपयोग करता हूं, जो यह जांचता है कि आपके पास चीजों के नवीनतम संस्करण हैं या नहीं। यह हमेशा मुझे बता रहा है कि क्रोम 15.x जीवन का अंत है या कुछ ऐसी चीज है

— JohnL

बेशक, आरएसएस मानक के लिए संस्करण संख्याएं केवल मानसिक हैं।

— जॉनएल

Answer 5

अन्य उत्तरों से अच्छे विचारों को दोहराए बिना, मेरे मन में एक समस्या है जिसे अभी तक संबोधित नहीं किया गया था।

यदि आप पिछड़े संगतता के लिए पुराने संस्करण के बीच कांटा करते हैं, और असंगत आधुनिकीकरण के लिए एक नया संस्करण है, तो आप उन्हें संस्करण संख्याओं के माध्यम से अलग नहीं कर सकते।

उदाहरण के लिए लिनक्स कर्नेल को वर्ष 2000 के आसपास पुरानी 2.4.x शाखा में कांटा गया था, जो शायद आज भी समर्थित है और 2.4.199 के रूप में गिना जाता है, जबकि नया संस्करण कई, कई वर्षों से 2.6 है, और 2.6.32 है पुरानी प्रणालियों के लिए, लेकिन नवीनतम गुठली के लिए 3.2।

यदि आपके पास अपनी रिलीज़ के बारे में दस्तावेज़ीकरण है, तो आप जानकारी को दोगुना कर देंगे और लोगों को बताएंगे कि 2012-2019 का संस्करण 2012 में 01/09 पर आया था। MH। लेकिन क्या होगा, अगर एक आखिरी पल बग का पता चलता है, और एक सप्ताह के लिए एक रिलीज में देरी होती है, लेकिन प्रलेखन, जहां नाम का उल्लेख किया गया है, पहले से ही तैयार है, शायद मुद्रित, प्रेस जानकारी बाहर है और इसी तरह। अब आपके पास एक विसंगति है जो समस्याग्रस्त है, अगर संस्करण 20120109 2012/01/13 पर आ गया।

एसक्यूएल में, सवाल यह है कि क्या आईडी को शब्दार्थ जानकारी ले जाना चाहिए अक्सर चर्चा की गई है, और परिणाम हमेशा होता है: इसे नरक की तरह से बचें! आप एक अनावश्यक निर्भरता पैदा कर रहे हैं। यह लाभ का नहीं हो सकता।

2006 में अपनी 04/10 योजना के साथ उबंटू को इसकी समस्या थी, जब संस्करण 6.04 में देरी हुई और 6.06 हो गई। वर्ष 3000 में जल्द ही अगली समस्या होगी! :)

Comments

01-जून -2005 से सबसे हालिया 2.4 श्रृंखला लिनक्स कर्नेल 2.4.31 है , हालांकि आप 09-अगस्त -2005 से पैच का उपयोग करके इसे बढ़ाकर 2.4.32-पूर्व 3 कर सकते हैं । सबसे नवीनतम stableश्रृंखला आधिकारिक कर्नेल वर्तमान में 2.6.32.54 (2012-01-12) और 3.1.10 (2012-01-18) हैं।

— बजे एक CVn

Answer 6

कई सॉफ्टवेयर पैकेज हैं जो वास्तव में एक संस्करण के रूप में तारीख का उपयोग करते हैं। उबंटू को ध्यान में आता है, जहां उनका संस्करण वाईवाईएमएम है। और Microsoft Office उत्पादों के लिए बिल्ड नंबर भी बिल्ड दिनांक की एन्कोडिंग हैं। जेफ एटवुड ने वर्जन नंबरिंग के बारे में कोडिंग हॉरर ब्लॉग पोस्ट लिखी , जिसमें यह सिफारिश भी शामिल है:

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

मेरी राय में, यह तब तक मायने नहीं रखता है जब तक आप सुसंगत हैं और एक बिल्ड संस्करण संख्या (जो भी हो) से जाने में सक्षम हैं और सभी कलाकृतियों को याद करते हैं जो आपके संस्करण नियंत्रण प्रणाली से उस बिल्ड में चली गईं। उपयोगकर्ता आमतौर पर संस्करण की जानकारी की बिल्कुल भी परवाह नहीं करते हैं, बल्कि सिस्टम द्वारा प्रदान की गई कार्यक्षमता के बारे में सोचते हैं। डेवलपर्स के लिए वर्जनिंग जानकारी केवल वास्तविक मूल्य की है।

Answer 7

सिमेंटिक वर्जनिंग का उपयोग करें - इस तरह, आपको कोड का निरीक्षण किए बिना संस्करणों के बीच किए जा रहे बदलावों के बारे में कुछ पता चलता है: http://semver.org/

Answer 8

संस्करण संख्याओं का उपयोग यह दिखाने का एक तरीका है कि परिवर्तन कितना बड़ा है

उदाहरण के लिए 2.4.3 का मतलब हो सकता है कि संस्करण 2 पूरे सिस्टम का प्रमुख बदलाव है। .4 एक मामूली अद्यतन है। और अंतिम .3 उस संस्करण के लिए एक छोटा बग फिक्स है। इस तरह से आसानी से पहचाने जाने योग्य यह प्रत्येक संस्करण के बीच कितना बदल गया है।

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

Answer 9

कुछ अच्छे उत्तर यहां पहले से ही हैं, लेकिन मैं एक ऐसे मामले को इंगित करना चाहूंगा जहां तिथियों का उपयोग करना सही अर्थ बनाता है: कोड के छोटे पुस्तकालयों या स्निपेट जहां कोड को अक्सर अपडेट किए जाने की संभावना होती है, लेकिन छोटे संस्करणों में बिना किसी एकल संस्करण के साथ पिछले करने के लिए नाटकीय रूप से भिन्न होता है। एक।

दूसरे शब्दों में, मैं उन स्थितियों के बारे में बात कर रहा हूँ जहाँ कोई वास्तविक "संस्करण संख्या" नहीं है, लेकिन मूल रूप से अर्ध-दैनिक रिपॉजिटरी डंप का एक प्रकार है।

जब मैं इस तरह के सामान के साथ आता हूं, तो मैं आमतौर पर पसंद का स्वागत करता हूं क्योंकि यह मेरे लिए यह जानना अधिक उपयोगी है कि मैं एक विशिष्ट संस्करण के बजाय अपेक्षाकृत वर्तमान स्क्रिप्ट / काम का उपयोग कर रहा हूं।

Answer 10

संस्करण संख्या के रूप में दिनांक विपणन के लिए अच्छा है। यदि लोग "विंडोज एनटी 5.0" का उपयोग कर रहे हैं, तो उन्हें एहसास नहीं हो सकता है कि यह अप्रचलित है। लेकिन अगर लोग अभी भी "विंडोज 2000" का उपयोग कर रहे हैं, तो उन्हें तुरंत पता चल जाएगा कि यह 12 साल पुराना ओएस है और इसे अपग्रेड करने के लिए प्रोत्साहित किया जाएगा।

हालांकि, यह "प्रमुख" और "मामूली" अपडेट के बीच अंतर करना कठिन बनाता है।

Comments

और मार्केटिंग आपको बेचने में मदद करती है ;)

— c69

उन्नयन के लिए उपयोगकर्ताओं की आवश्यकता या "प्रोत्साहित" क्यों किया जाना चाहिए, यदि सॉफ़्टवेयर उनकी ज़रूरतों को पूरा करता है (सुरक्षा का उचित स्तर प्रदान करने सहित)?

— बजे एक CVn

क्योंकि इसके लिए समर्थन गिरा दिया जाता है, और आपको सुरक्षा अपडेट मिलना बंद हो जाता है।

— जॉनएल

Answer 11

संस्करण संख्याओं के रूप में दिनांक का उपयोग करने में समस्या

यहाँ उत्तर अच्छे हैं, लेकिन मैंने किसी को तारीखों का उपयोग करने के साथ इस चिंता का समाधान नहीं देखा: उपयोगकर्ता यह निर्धारित नहीं कर सकता कि कितनी बार संशोधन किए गए हैं।

जो मैं कहने की कोशिश कर रहा हूं वह यह है कि मैं बता सकता हूं कि विंडोज 3.1 और विंडोज 7 बहुत अलग हैं ... और शायद असंगत हैं। विंडोज 95 और विंडोज 2000 मुझे बताता है कि किस वर्ष में उत्पाद पेश किया गया था।

उदाहरण के लिए, पायथन के साथ, मुझे पता है कि 2.7.2 संस्करण 2.4.6 से विकसित हुआ है। यदि मैं आगे देखता हूं, तो मैं देखता हूं कि संस्करण 2.4.6 को 19 दिसंबर, 2008 को जारी किया गया था; और वह संस्करण 2.7.2 11 जून, 2011 को जारी किया गया था। इसमें से, मैं एक उत्पाद की स्थिरता (यानी, आवृत्ति की आवृत्ति) के बारे में एक राय बना सकता हूं।

यदि, इसके बजाय, पायथन ने रिलीज की तारीखों का उपयोग किया था, तो मुझे नहीं पता कि ये उत्पाद कैसे जुड़े हो सकते हैं। आगे भ्रम की स्थिति पैदा होगी, क्योंकि अजगर 3.1.4 भी 11 जून, 2011 को जारी किया गया था (पायथन 2.7.2 के समान)।

संक्षेप में, मुझे नहीं लगता कि, अपने आप में, दिनांक-संस्करण मूल्यवान है।

Answer 12

मुझे यह विचार पसंद नहीं है, दूसरों द्वारा पहले से ही वर्णित कारणों के लिए। बस प्रमुख .minor.bugfix योजना का उपयोग करें - एक कारण है कि ज्यादातर लोग इस तरह से करते हैं।

लेकिन आप जो भी करते हैं: एक संस्करण-नामकरण योजना चुनें, और उससे चिपके रहें । इसे विंडोज की तरह न करें, जहां वे हर रिलीज़ के साथ स्कीम बदलते हैं। और इसे एंड्रॉइड की तरह न करें, जहां प्रत्येक रिलीज़ में एक एपीआई संस्करण संख्या (8) है, एक संस्करण संख्या जो विपणन (2.2) और एक बेवकूफ नाम (फ्रायो) के लिए है।

Answer 13

संस्करण के रूप में दिनांक

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

योजना हम उपयोग करते हैं

मैंने यह दावा नहीं किया कि हमारा सिस्टम, ऊपर जैसा स्पष्ट ब्रांड बनाता है। अब हम एक चार भाग योजना का उपयोग करते हैं। एक संस्करण संख्या, स्थिति, दिनांक और एक चेकसम।

1200_GLD_120120_F0D1

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

तो हम एक अनुक्रम हो सकता है

1200_TST_120110_EF45
1200_GLD_120120_F0D1
1201_FIX_120125_123E
1201_TST_120130_31A5
1201_TST_120131_FDFD

हम आम तौर पर केवल ग्राहक के लिए मुख्य संस्करण संख्याओं का उल्लेख करते हैं "12" लेकिन एक ग्राहक को 12 का नवीनतम स्वर्ण संस्करण मिलेगा अर्थात 1200_GLD_120120_F0D1 जब तक कि उन्हें फिक्स की आवश्यकता न हो।

Answer 14

मान लें कि कुछ ग्राहक आपके उत्पाद के संस्करण दो का उपयोग करते हैं, और कुछ ने संस्करण तीन में अपग्रेड किया है, और यह अपग्रेड हल्के ढंग से किया गया निर्णय नहीं है।

कहें कि संस्करण दो का अंतिम संस्करण 2.3.2 है, और संस्करण तीन 3.0.3 पर है। अब आपको एक भेद्यता मिलती है जिसे बिल्कुल ठीक करने की आवश्यकता होती है, इसलिए आप उसी दिन 2.3.3 और 3.0.4 जारी करते हैं। क्या आप देख सकते हैं कि रिलीज़ की तारीख पूरी तरह अप्रासंगिक है? आपने 2013 में संस्करण दो पर काम बंद कर दिया होगा और तब से केवल कुछ आवश्यक बग फिक्स जारी किए हैं। संस्करण संख्या की तुलना में तारीख अप्रासंगिक है।

Answer 15

मुझे लगता है कि यह बहुत अच्छा काम करता है। मैं इसे कुछ आंतरिक सॉफ़्टवेयर (yyyy.mm.dd) और कुछ खुले स्रोत सॉफ़्टवेयर के लिए उपयोग करता हूं जिन्हें मैंने जारी किया था।

यह सभी मामलों में काम नहीं कर सकता है।

Comments

इस मामले में, हम बस "इसका नया साल देख सकते हैं!" नववर्ष की शुभकामना...!

— यौषा अलाय्यूब

Answer 16

तकनीकी रूप से यह संस्करण संख्या के लिए दिनांक का उपयोग नहीं कर सकता है, लेकिन यह ग्राहक के लिए दिनांक संख्या दिखा सकता है। उदाहरण के लिए, macOS 16.7.23 --- इसका मतलब है कि: 23/7/2016

मुझे लगता है कि तकनीक समस्या नहीं है, समस्या यह है कि यह कैसा लगता है? यदि तारीख नंबर का उपयोग करें जो सॉफ्टवेयर को जीवित कर सकता है, तो जीवित है, एक आदमी की तरह जो जन्मदिन की संख्या है। हर साल हम बड़े हो रहे हैं, उसी तरह जैसे सॉफ्टवेयर बढ़ रहा है।

बिल्डिंग नंबर मशीन की तरह दिखता है, मशीन, कोई जीवित नहीं, कोई जीवित नहीं।