वर्जन नंबर कैसे करें?

Question

मेरी कंपनी एक उत्पाद का निर्माण कर रही है। यह SVN द्वारा संस्करणित होने जा रहा है। यह एक व्हाट्सएप है इसलिए मूल रूप से कभी भी एक संस्करण नहीं होगा, जिसमें कुछ विशेषताएं नहीं हैं और इस तरह हमेशा बीटा के रूप में लेबल किया जा सकता है। लेकिन जब से यह एक कॉर्पोरेट उत्पाद होने जा रहा है, मैं वास्तव में वहां पर "अस्थिर वॉचआउट" नहीं चाहता हूं। तो आप संस्करण के बारे में कैसे जाएंगे? 1.0 स्थिर है? क्या बिल्ड की तारीख संस्करण संख्या में होनी चाहिए? बताइए आप लोग क्या सोच रहे हैं!

Comments

कुछ समय बाद, जब आप ~ ६ या ~ पर पहुँचते हैं, तो आपको २०१० (या जो भी अच्छा वर्ष) पर जाना चाहिए;)

— अनाम

Arg ... कृपया, मैं आपसे भीख माँगता हूँ, नहीं। :-D

— DevSolar

msdn.microsoft.com/en-us/library/system.version.aspx रिमार्क्स में

— कीकरमारू

कुछ वर्षों के लिए तारीखों के साथ जाने के बाद, संख्याओं पर वापस जाएं, लेकिन एचडी , फुलएचडी , 4K , ग्लूटेन-फ्री जैसे जो भी शांत हों , उनमें buzzwords शामिल करें । तो सॉफ्टवेयर उद्योग से बाहर के लोग संबंधित हो सकते हैं।

— एमिल बर्जरॉन

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

— दक्षिणावर्त

Answer 1

[ प्रमुख ] [ लघु ] [ जारी ]] [ निर्माण ]

प्रमुख : वास्तव में एक विपणन निर्णय। क्या आप संस्करण 1.0 को कॉल करने के लिए तैयार हैं? क्या कंपनी इसे एक प्रमुख संस्करण मानती है जिसके लिए ग्राहकों को अधिक भुगतान करना पड़ सकता है, या क्या यह वर्तमान प्रमुख संस्करण का अद्यतन है जो मुफ्त हो सकता है? एक R & D निर्णय कम और एक उत्पाद निर्णय अधिक।

मामूली : 0 से शुरू होता है जब भी प्रमुख वेतन वृद्धि होती है। सार्वजनिक होने वाले हर संस्करण के लिए +1।

रिलीज : हर बार जब आप एक विकास मील का पत्थर मारते हैं और उत्पाद को जारी करते हैं, यहां तक ​​कि आंतरिक रूप से (उदाहरण के लिए क्यूए), इसे बढ़ाते हैं। यह संगठन में टीमों के बीच संचार के लिए विशेष रूप से महत्वपूर्ण है। कहने की जरूरत नहीं है, एक ही 'रिलीज' को दो बार (यहां तक ​​कि आंतरिक रूप से) जारी न करें। मामूली ++ या प्रमुख ++ पर 0 पर रीसेट करें।

बिल्ड : एक SVN संशोधन हो सकता है, मुझे लगता है कि सबसे अच्छा काम करता है।

उदाहरण
मेरा वर्तमान क्रोम: 83.0.4103.61

Comments

यह लगभग मेरे सॉफ़्टवेयर के संस्करण की मेरी परिभाषा से मेल खाता है। हालाँकि मैं "मामूली" संस्करण संख्या बढ़ाते हुए रिलीज़ को 0 पर रीसेट करता हूँ।

— BlaM

यदि आप गिट का उपयोग करते हैं तो नाबालिग के लिए क्या है?

— ब्रायन कार्लटन

@Brain: पर एक नज़र डालेंgit describe

— Daenyth

यह उत्तर इतना पुराना है ... मुझे विश्वास नहीं हो रहा है कि मैंने कभी SVN का उपयोग किया है। : OI आश्चर्य है कि Git के लिए सबसे अच्छा अभ्यास क्या होगा। हो सकता है कि कमिट के हैश के पहले कुछ अंक? तो "जीआईटी शो [बिल्ड]" करते समय एक अनूठा मैच होने का एक अच्छा मौका है?

— असफ लावी

"अल्फ़ाज़" और "बेटस" के बारे में क्या? क्या आप सॉफ़्टवेयर के अल्फ़ा या बीटा से बाहर निकलने से पहले या उसके बाद संस्करण संख्या में वृद्धि करते हैं?

— पॉसफ़न 12

Answer 2

xyzg

जी में वृद्धि अस्थिर हैं। (या RC) z में वृद्धि स्थिर और मतलब बग फिक्स हैं।
y में वृद्धि स्थिर और नई सुविधाओं का मतलब है।
एक्स में वेतन वृद्धि स्थिर है, 100% पिछड़े संगतता के बिना प्रमुख रिलीज।

Comments

क्या यह आपका तरीका या एक आम उपयोग है?

— कैनावर

जी स्पॉट के बारे में मुझे यकीन नहीं है, बाकी सब सामान्य है।

— इते मूव -मालिमोवका

घटकों के लिए अच्छी संस्करण योजना। लेकिन एक वाणिज्यिक उत्पाद के लिए, xy से परे सब कुछ सिर्फ ग्राहक को भ्रमित कर रहा है और संचार को मुश्किल बना रहा है IMHO। विशेष रूप से वेब ऐप, जिसके लिए ग्राहक को माइग्रेट करने की आवश्यकता होती है - "रिलीज़ जल्दी, रिलीज़ अक्सर" इसे वहां नहीं काटता है ...

— DevSolar

लेकिन यह डिबगिंग के लिए अभी भी अच्छा होगा अगर इसकी कोई चीज जो ग्राहक वास्तव में स्थापित करता है / खरीदता है वह पूर्ण संस्करण कहीं छिपा हुआ है।

— फराउन

@ ItayMoav-Malimovka इसे स्वीकार करते हैं, आपने 'जी' का इस्तेमाल किया है ताकि आप उस मजाक को बना सकें।

— आंद्रेई

Answer 3

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

खबरदार, यह एक लंबा पाठ है, और इस तरह के घटक संस्करण बनाम उत्पाद संस्करण और सामान में जाता है। यह ओएसएस समुदाय में लोकप्रिय कुछ संस्करण योजनाओं पर भी मजबूत राय व्यक्त करता है, लेकिन मेरे पास है, इसलिए मैं उन्हें व्यक्त करता हूं। ;-)

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

संपादित करें: सारांश के रूप में, यह संस्करण फ़ाइलों, घटकों और समग्र उत्पाद के बीच अंतर करता है। यह घटकों और उत्पाद के लिए अलग xy versoning की एक प्रणाली का उपयोग करता है, दोनों के बीच एक अच्छी परस्पर निर्भरता के साथ यह पता लगाता है कि घटक संस्करण किस उत्पाद संस्करण से संबंधित है। यह सिस्टम को तोड़ने के बिना अल्फा / बीटा / रिलीज़ / पैच चक्र को कैसे संभालना है, इसके बारे में भी बात करता है। वास्तव में, यह पूरे विकास चक्र के लिए एक मॉडस ऑपरेंडी है, इसलिए आप चेरी-पिक करना चाहते हैं। ;-)

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

Comments

जैसा कि GmonC ने कहा, यह एक पुराना धागा है, लेकिन मैंने इसे पाया, आपके लिंक किए गए दस्तावेज़ को पढ़ा, और अच्छी तरह से कहना चाहता था। कुछ उत्कृष्ट विचार उत्तेजक आइटम वहाँ। धन्यवाद! +1

— कार्वेल फेंटन

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

— jontyc

Answer 4

अपने आप को विकिपीडिया से कुछ प्रेरणा प्राप्त करें: "सॉफ्टवेयर संस्करण"

एक और "नया" और "अपेक्षाकृत लोकप्रिय" विकल्प सिमेंटिक संस्करण है

सारांश:

एक संस्करण संख्या MAJOR.MINOR.PATCH को देखते हुए, वेतन वृद्धि:

1. जब आप असंगत एपीआई परिवर्तन करते हैं, तो मुख्य संस्करण
2. जब आप बैकवर्ड-संगत तरीके से कार्यक्षमता जोड़ते हैं, तो माइनर संस्करण और
3. जब आप पीछे की ओर संगत बग फिक्स करते हैं तो पैटच संस्करण।

प्री-रिलीज़ और बिल्ड मेटाडेटा के लिए अतिरिक्त लेबल MAJOR.MINOR.PATCH प्रारूप के एक्सटेंशन के रूप में उपलब्ध हैं।

Comments

@ रवि - शायद, लेकिन यह बर्बरता हो सकती है। SO को संपादित करने के लिए प्रतिष्ठा की आवश्यकता होती है। कम से कम एक सारांश इस सवाल को कम करने वाले लोगों के लिए बेहतर होगा।

— नाथन लॉन्ग

@ नथन, यदि आप एसओ का उपयोग करते हैं, तो आप निश्चित रूप से विकिपीडिया के लेख संपादित इतिहास का उपयोग कर सकते हैं।

— सीएमगिरिआ

@iconiK - यदि आप एसओ का उपयोग करते हैं, तो आप निश्चित रूप से समझते हैं कि "यहां एक स्पष्ट पृष्ठ पर अन्य उत्तरों के साथ एक संक्षिप्त जवाब है" से अधिक उपयोगी है "यहां एक अलग साइट का लिंक है जहां आप एक लेख के पुराने संस्करणों के माध्यम से खुदाई कर सकते हैं और शायद कुछ प्रासंगिक मिल जाए। ”

— नाथन लॉन्ग

Answer 5

ऐ बी सी डी

वृद्धि: जब
- डी : बग फिक्स
- सी : रखरखाव, जैसे प्रदर्शन में सुधार
- बी : नई विशेषताएं
- एक : वास्तुकला परिवर्तन

अनिवार्य सबसे बाईं ओर है उदाहरण के लिए यदि कोई नई सुविधा और एक बग तय किया गया है तो आपको केवल बी बढ़ाना होगा ।

Comments

वास्तु परिवर्तन के कुछ उदाहरण क्या हैं?

— ईगलीन 22

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

— एलेक्सिस गामरा

Answer 6

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

मूल रूप से यह सेमेटिक वर्जनिंग 2.0 से दूर है, लेकिन यह उतना सख्त नहीं है।

अर्ध-शब्दार्थ संस्करण खंड:

<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]

प्राथमिक रिलीज़ सेगमेंट प्रारूप:

MARKETTING.MAJOR.MINOR.PATCH

प्रत्येक सेगमेंट में अल्फ़ान्यूमेरिक्स की अनुमति होनी चाहिए, लेकिन तार्किक वृद्धिशील परिवर्तनों के लिए शुद्ध न्यूमेरिक्स की सिफारिश की जाती है।

SemVer की तरह, मैं मेजर, माइनर, और पैच कंपोनेंट्स को रिवर्स कम्पैटिबिलिटी टियर्स का प्रतिनिधित्व करने के लिए सलाह देता हूं, लेकिन मैं मार्केटिंग कंपोनेंट को तैयार करने की भी सलाह देता हूं । यह उत्पाद मालिकों, सुविधा महाकाव्यों / समूहों, और व्यावसायिक चिंताओं को तकनीकी संगतता चिंताओं से स्वतंत्र प्राथमिक घटक को टक्कर देने की अनुमति देता है।

अन्य उत्तरों के विपरीत, मैंने प्राथमिक सेगमेंट में बिल्ड नंबर को जोड़ने की सिफारिश नहीं की है। इसके बजाय, '+' के बाद एक पोस्ट-रिलीज़ सेगमेंट जोड़ें (उदा: 1.1.0.0 + build.42)। SemVer इस बिल्ड मेटाडेटा को कॉल करता है, लेकिन मुझे लगता है कि पोस्ट-रिलीज़ सेगमेंट स्पष्ट है। यह सेगमेंट प्राथमिक डेटा सेगमेंट में अनुकूलता जानकारी से संबंधित नहीं होने के कारण प्रत्यय डेटा घोषित करने के लिए बहुत अच्छा है। आपका निरंतर एकीकरण बनाता है फिर पिछले रिलीज नंबर को एक वृद्धिशील बिल्ड नंबर के साथ जोड़ा जा सकता है जो प्रत्येक प्राथमिक रिलीज के बाद रीसेट करता है (उदा: 1.1.0.0 -> 1.1.0.0 + build.1 -> 1.1.0.0 + build.2 -> १.१.०.१)। कुछ लोग बारी-बारी से यहाँ svn revision नंबर डालना चाहते हैं या git कमिट श को कोड रिपॉजिटरी में बाँधना आसान बनाते हैं। एक अन्य विकल्प यह है कि हॉटफ़िक्स और पैच के लिए रिलीज़-बाद के सेगमेंट का उपयोग किया जाए, इसके लिए एक नया प्राथमिक रिलीज़ कंपोनेंट जोड़ने पर विचार किया जा सकता है। पैच घटक बढ़ने पर इसे हमेशा गिराया जा सकता है, क्योंकि संस्करण प्रभावी रूप से बाएं-संरेखित और क्रमबद्ध हैं।

रिलीज़ और पोस्ट-रिलीज़ सेगमेंट के अलावा, लोग अक्सर अल्फ़ा, बेटास और रिलीज़ उम्मीदवारों जैसे लगभग-स्थिर प्री-रिलीज़ को इंगित करने के लिए प्री-रिलीज़ सेगमेंट का उपयोग करना चाहते हैं । इस के लिए SemVer दृष्टिकोण अच्छी तरह से काम करता है, लेकिन मैं अल्फा-न्यूमेरिक क्लासिफायर से संख्यात्मक घटकों को अलग करने की सलाह देता हूं (उदा: 1.2.0.0 + Alpha.2 या 1.2.0.0 + RC.2)। आम तौर पर आप रिलीज़ सेगमेंट को एक ही समय में रिलीज़ करने के बाद रिलीज़ सेगमेंट में जोड़ देंगे और फिर प्री-रिलीज़ सेगमेंट को छोड़ देंगे जब आप अगली बार उन्हें प्राइमरी रिलीज़ सेगमेंट से बाहर कर देंगे (उदा: 1.0.1.2 -> 1.2.0.0-RC.1 - > 1.2.0.0)। प्री-रिलीज़ सेगमेंट को यह इंगित करने के लिए जोड़ा जाता है कि रिलीज़ संस्करण सामने आ रहा है, आमतौर पर अधिक गहराई से परीक्षण और साझा करने के लिए सुविधाओं का एक निश्चित सेट जो अधिक मिनटों के आधार पर मिनट टू मिनट नहीं बदलता है।

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

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

Answer 7

"संस्करण संख्या" आपके आंतरिक संस्करण नियंत्रण प्रणाली के लिए एक मामला है। रिलीज़ नंबर एक अलग मामला है (और KEPT अलग होना चाहिए)।

एक साधारण MAJOR.MINOR रिलीज सिस्टम (जैसे v1.27) से चिपके रहें, जहां MAJOR संगतता स्तर है (संस्करण 2.x संस्करण 1.x से कम या कम से कम प्रमुख रूप से असंगत है) और MINOR आपकी बगफिक्स रिलीज़ या मामूली संवर्द्धन है । जब तक आप XY प्रारूप का पालन करते हैं, आप YEAR.MONTH (2009.12) या YEAR.RELEASE (2009.3) जैसी अन्य प्रणालियों का भी उपयोग कर सकते हैं। लेकिन वास्तव में आप शायद सबसे अच्छी तरह से MAJOR.MINOR से चिपके रहते हैं जब तक कि आपके पास एक अच्छा कारण न हो।

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

अपने आंतरिक (प्राथमिक रूप से वितरित) संस्करण नियंत्रण प्रणाली में शाखाओं और टैगों का उपयोग करें ताकि क्रमशः MAJORS और MINORS से संबंधित विशिष्ट आंतरिक संस्करण संख्याओं को चिह्नित किया जा सके।

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

Comments

मैं सहमत हूं कि उपयोगकर्ता जो देखता है और जो आप बनाते हैं वह दो अलग-अलग चीजें हैं, लेकिन क्या आपको दोनों को किसी भी तरह से लिंक नहीं करना है? यानी आपकी रिलीज़ और वर्जन नंबर संबंधित होने चाहिए और आपको वर्जन नंबर फॉर्म जारी करने में सक्षम होना चाहिए

— जेफरी कैमरन

ओपन सोर्स के साथ, हम बिल्ड नंबरों की परवाह नहीं करते हैं। हम स्रोत कोड वितरित करते हैं, और बिल्ड डिस्ट्रोस तक होते हैं। यदि वे अपने संस्करण में बग देखते हैं, लेकिन स्रोत रिलीज में नहीं, तो उन्होंने बिल्ड में कुछ गलत किया। अन्यथा, यह उस रिलीज़ टैग का कोड है। वीसी में भी टैग दिखाई दे रहे हैं।

— ली बी

Answer 8

यह बहुत लोकप्रिय है इन दिनों बस तोड़फोड़ संशोधन संख्या का उपयोग करने के लिए।

Comments

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

— DevSolar

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

— rmeador

Answer 9

यदि यह एसवीएन में है तो एसवीएन संशोधन संख्या का उपयोग क्यों नहीं किया जाता है?

यदि आप इस वेब पेज के नीचे दाईं ओर देखते हैं तो आपको स्टैक ओवरफ्लो संस्करण संख्या दिखाई देगी जो कि SVN संशोधन संख्या है।

Comments

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

— DevSolar

Answer 10

वर्जनिंग आपके ऊपर है; मैंने पहले संस्करण में 1.0 डाला था, जिस पर मुझे भरोसा था। आप इसे अन्य संस्करणों के साथ जल्दी से फॉलो करना चाह सकते हैं, क्योंकि कुछ सॉफ्टवेयर विक्रेताओं ने 1.0 को खराब प्रतिष्ठा दी है।

आप उपयोग किए गए सटीक निर्माण के लिए संस्करण संख्या को बांधने का कोई तरीका चाहते हैं, लेकिन आप शायद इसे अपने अंतिम उपयोगकर्ताओं के लिए अच्छा और सरल बनाना चाहते हैं। मानक संस्करण संख्याओं का उपयोग करने पर विचार करें, और शामिल किए गए संस्करण संख्या के साथ SVN रिपॉजिटरी को टैग करें।

Answer 11

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

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

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

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

Answer 12

संस्करण योजना: [प्रमुख]। [लघु]। [भक्ति] [चिह्न]
[प्रमुख]: वृद्धि अगर आपके पास विकास में भारी बदलाव है।
[मामूली]: वृद्धि अगर आप विकास में मामूली बदलाव है।
[devrel]: अगर आपके पास बग फिक्स है तो वेतन वृद्धि। प्रमुख ++ या मामूली ++ शून्य पर रीसेट करें।
[चिह्न]: ए, बी या आरसी: ए एक अल्फा रिलीज है, बी बीटा रिलीज है, और आरसी एक रिलीज उम्मीदवार है। ध्यान दें कि संस्करण 1.3.57a या 1.3.57b या 1.3.57rc जैसे संस्करण 1.3.57 संस्करण से पहले हैं। 0.0.0 से शुरू करें।

Answer 13

हमने मुख्य संस्करण को बढ़ाने के लिए निर्णय लेने में बहुत अधिक समय बिताया है। कुछ दुकानें शायद ही कभी ऐसा करती हैं ताकि आपके पास १.२५.३ जैसी रिलीज़ हो और अन्य लोग इसे १५.० देने के लिए कभी भी रिलीज़ करें

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

Year.Release.build

• वर्ष = वर्तमान वर्ष
• नई कार्यक्षमता के साथ सार्वजनिक रिलीज़ का = अनुक्रम # जारी - हर साल 1 पर रीसेट करें
• बग फिक्स और आंतरिक रिलीज के लिए बिल्ड = वृद्धि

संपादित करें

** अब यह एक आंतरिक ऐप के लिए था जिसे लगातार बढ़ाया गया था **

यह शायद उन व्यावसायिक ऐप के लिए काम नहीं करेगा जहां विपणन और वित्तीय उद्देश्यों के लिए वर्ष के विभिन्न समयों में प्रमुख रिलीज होना महत्वपूर्ण है।

Comments

... जो नए साल की पहली रिलीज़ को "प्रमुख रिलीज़" स्वचालित रूप से बनाता है, चाहे कितना भी महत्वपूर्ण बदलाव क्यों न हो। और आप वर्ष के भीतर एक "प्रमुख" रिलीज़ नहीं कर सकते , या तो ...

— DevSolar

Answer 14

इस प्रश्न के मौजूद होने का कारण यह है कि हमारे पास कॉन्फ़िगरेशन प्रबंधन करने के तरीके पर एक भी सहमति नहीं है।

जिस तरह से मैं संस्करण संख्या करना पसंद करता हूं, वह 1. 1 से केवल वृद्धि पूर्णांक है। मुझे एक बहु भाग संस्करण संख्या नहीं चाहिए जो मुझे समझाना होगा या दस्तावेज़। और मैं SVN रेव नंबर का उपयोग नहीं करना चाहता क्योंकि इसके लिए कुछ समझाने की भी आवश्यकता होगी।

ऐसा करने के लिए आपको SVN के शीर्ष पर कुछ रिलीज़ स्क्रिप्ट की आवश्यकता होगी

Answer 15

मुझे क्षेत्र में बहुत कम अनुभव है। हालाँकि, मैं यहाँ क्या करूँगा:

1. संशोधन के लिए एक योजना चुनें और उस पर टिके रहें। निरतंरता बनाए रखें।
2. प्रत्येक संस्करण परिवर्तन को एक महत्वपूर्ण परिवर्तन का प्रतिनिधित्व करना चाहिए । परिवर्तन कितना छोटा है और संस्करण संख्या में परिलक्षित होने वाले परिवर्तन का स्तर आपके ऊपर है।

बेशक, आप सिर्फ svn संशोधन संख्या का उपयोग कर सकते हैं --- जैसे कई अन्य ने सुझाव दिया है !!!

आशा है कि ये आपकी मदद करेगा।

Answer 16

हम एक साधारण प्रमुख .minor.julian_date सिंटैक्स का उपयोग करते हैं।

कहाँ पे;

• मेजर - पहली रिलीज़ 1 है और फिर जब हम प्रमुख नई विशेषताओं या बदलावों को पेश करते हैं तो वे इस संख्या को पीछे नहीं बढ़ाते हैं।
• मामूली - प्रमुख मील का पत्थर जारी करता है। उत्पादन द्वारा धकेल दिए गए प्रत्येक निर्माण के लिए यह संख्या बढ़ जाती है।
• julian_date - जूलियन दिवस का निर्माण QA को धकेल दिया गया था।

1/15 पर QA के लिए धकेल दी गई पहली रिलीज़ का उदाहरण है -> 1.0.015
3/4 पर उत्पादन के लिए धकेले गए पहले रिलीज़ का उदाहरण है -> 1.1.063

यह सही नहीं है, लेकिन आसान है क्योंकि हम प्रतिदिन क्यूए के पास पहुंचते हैं।

Answer 17

यहाँ कुछ अच्छी जानकारी:

फ़ाइल / असेंबली संस्करण कब बदलें

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

गैर-शिपिंग बिल्ड सामान्य तौर पर, मैं गैर-शिपिंग असेंबली संस्करणों को शिपिंग बिल्ड के बीच रखने की सलाह देता हूं। संस्करण बेमेल के कारण यह दृढ़ता से नामित विधानसभा लोडिंग समस्याओं से बचा जाता है। कुछ लोग प्रत्येक बिल्ड के लिए नए असेंबली संस्करणों को पुनर्निर्देशित करने के लिए प्रकाशक नीति का उपयोग करना पसंद करते हैं। मैं इसके खिलाफ गैर-शिपिंग बिल्ड के लिए सलाह देता हूं, हालांकि: यह लोडिंग की सभी समस्याओं से नहीं बचता है। उदाहरण के लिए, यदि कोई साझेदार आपके ऐप की प्रतिलिपि बनाता है, तो वे प्रकाशक नीति को स्थापित करना नहीं जानते होंगे। फिर, आपके ऐप को उनके लिए तोड़ दिया जाएगा, भले ही यह आपकी मशीन पर ठीक काम करता हो।

लेकिन, अगर ऐसे मामले हैं जहां एक ही मशीन पर अलग-अलग एप्लिकेशन को आपकी असेंबली के अलग-अलग वर्जन पर बाइंड करने की जरूरत है, तो मैं आपको अलग-अलग असेंबली वर्जन देने की सलाह देता हूं ताकि प्रत्येक एप के लिए सही एक का उपयोग लोडरफॉम / आदि का उपयोग किए बिना किया जा सके।

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

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

Answer 18

या अपने 'सोचा' संस्करण संख्या अल्पविराम संख्या का उपयोग करने के लिए .. zB:

1.0.101 // संशोधन 101, रिलीज़

या 1.0.101-090303 // रिलीज की तारीख के साथ, मैं इसका उपयोग करता हूं