अर्थ वर्जनिंग 1.0.0-rc.1

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

बहुत अधिक निर्भरता वाली प्रणाली में, नए पैकेजों की रिहाई जल्दी से एक दुःस्वप्न में बदल सकती है। यदि निर्भरता बहुत मजबूत है, तो आप सभी निर्भर पैकेजों के संस्करणों को अपडेट किए बिना पैकेज को अपडेट नहीं कर सकते। यदि निर्भरता बहुत ढीली है, तो आपको लाइसेंस वाले संस्करणों के साथ समस्या होगी। "निर्भरता का नरक" तब होता है जब आप बहुत मजबूत होते हैं, या इसके विपरीत, बहुत ढीली निर्भरता आपको अपनी परियोजना को आसानी से और सुरक्षित रूप से विकसित करने की अनुमति नहीं देती है।

इस समस्या के समाधान के रूप में, मैं नियमों का एक सरल सेट प्रस्तावित करता हूं जो निर्धारित करता है कि संस्करण संख्याओं को कैसे असाइन और बढ़ाया जाए। सिस्टम को काम करने के लिए, शुरुआत के लिए, आपको एक खुली एपीआई घोषित करने की आवश्यकता है। यह एक सरल और स्पष्ट दस्तावेज होना चाहिए। XYZ प्रारूप (Major.Minor.Patch) में संस्करण संख्या पर विचार करें।
एपीआई को प्रभावित नहीं करने वाली त्रुटियों को ठीक करते समय, पैच संस्करण बढ़ाया जाता है। जब आप पिछड़े संगतता को बनाए रखते हुए एपीआई को जोड़ते हैं या बदलते हैं, तो माइनर संस्करण बढ़ जाता है। यदि बैकवर्ड संगतता बनाए रखने के बिना एपीआई को बदल दिया जाता है, तो मेजर संस्करण बढ़ाया जाता है।

मैं इस प्रणाली को "सिमेंटिक वर्जनिंग" कहता हूं। इस योजना के अनुसार, संस्करण संख्याएं और वे कैसे बदलते हैं मुख्य कोड की समझ में आता है और यह संस्करण से संस्करण में कैसे बदल गया।

शब्दार्थ संस्करण विशिष्टता

इस दस्तावेज में "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" कीवर्ड को RFC के अनुसार व्याख्यायित किया जाना चाहिए 2119।

1. सिमेंटिक वर्जन MUST का उपयोग करने वाले एक सॉफ्टवेयर उत्पाद का एक खुला एपीआई है। यह एपीआई कोड के अंदर या आवेदन दस्तावेज में घोषित किया जाना चाहिए। एपीआई सटीक और व्यापक होना चाहिए।
2. संस्करण संख्या में XYZ शामिल होना चाहिए, जहां X, Y और Z सकारात्मक संख्या हैं। X मेजर वर्जन है, Y माइनर वर्जन है और Z पैच वर्जन है। प्रत्येक तत्व को एक के वेतन वृद्धि में वृद्धि करनी चाहिए। उदाहरण के लिए: 1.9.0 -> 1.10.0 -> 1.11.0।
3. जब मेजर वर्जन बढ़ता है, तो माइनर और पैच वर्जन को रीसेट करना होगा। जब माइनर संस्करण को बढ़ाया जाता है, तो पैच संस्करण को शून्य पर रीसेट किया जाना चाहिए। उदाहरण के लिए: 1.1.3 -> 2.0.0 और 2.1.7 -> 2.2.0।
4. पैकेज संस्करण जारी होने के बाद, इस पैकेज में कोई बदलाव नहीं किया जाना चाहिए। सभी परिवर्तनों को नए संस्करण के साथ जारी किया जाना चाहिए।
5. विकास की शुरुआत में, मेजर संस्करण शून्य (0.yz) है। इस अवधि के दौरान, किसी भी समय कुछ बदल सकता है। एक खुला एपीआई जरूरी स्थिर नहीं माना जाना चाहिए।
6. संस्करण 1.0.0 एक खुले एपीआई को परिभाषित करता है। कैसे संस्करण संख्या में परिवर्तन इस खुले एपीआई पर निर्भर करता है।
7. पैच संस्करण Z (xyZ | x> 0) केवल तभी बढ़ाया जाना चाहिए जब बग फिक्स पिछले संस्करणों के साथ पीछे की ओर संगत हों। बग फिक्स गलत व्यवहार को खत्म करता है।
8. लघु संस्करण Y (xYz | x> 0) यदि पिछले संस्करणों के साथ सुधार किए गए हैं, तो आवश्यक रूप से वृद्धि की जानी चाहिए। किसी भी एपीआई तत्व के रूप में चिह्नित होने पर माइनर संस्करण को बढ़ाया जाना चाहिए। माइनर संस्करण MAY को महत्वपूर्ण नई सुविधाओं या संवर्द्धन के साथ उन्नत किया जाएगा। माइनर संस्करण MAY में पैच संस्करण में परिवर्तन शामिल हैं। पैच संस्करण को रीसेट किया जाना चाहिए जब माइनर संस्करण बदलता है।
9. मुख्य संस्करण X (Xyz | X> 0) यदि सुधार किए गए हैं तो पिछले संस्करणों के साथ असंगत होने पर वृद्धि की जानी चाहिए। प्रमुख संस्करण MAY में माइनर और पैच संस्करणों में परिवर्तन शामिल हैं। पैच और माइनर संस्करणों को रीसेट किया जाना चाहिए जब मेजर संस्करण बदल जाता है।
10. प्रारंभिक संस्करण MAY को डैश और पैच वर्जन के तुरंत बाद की अवधि से अलग पहचानकर्ता द्वारा इंगित किया जाना चाहिए। पहचानकर्ता में वर्ण [0-9A-Za-z-] होते हैं। पूर्वावलोकन संस्करण में समान सामान्य संस्करण की तुलना में कम प्राथमिकता है। उदाहरण: 1.0.0-अल्फा, 1.0.0-अल्फा.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92।
11. पैच या पूर्व-रिलीज़ संस्करण के तुरंत बाद बिल्ड संस्करण MAY को प्लस चिह्न और डॉट-सीमांकित पहचानकर्ता द्वारा इंगित किया जाना चाहिए। पहचानकर्ता में वर्ण [0-9A-Za-z-] होते हैं। बिल्ड संस्करण समान सामान्य संस्करण पर पूर्वता लेता है।
    उदाहरण: 1.0.0 + build.1, 1.3.7 + build.11.e0f985a।
12. प्राथमिकता को मेजर, माइनर, पैच, प्रारंभिक और बिल्ड संस्करणों में विभाजित करके गणना की जानी चाहिए। मेजर, माइनर और पैच वर्जन में हमेशा नंबर होते हैं। प्रारंभिक और असेंबली संस्करण आवश्यक रूप से प्रत्येक पहचानकर्ता की डॉट द्वारा अलग-अलग बिंदुओं की तुलना करके क्रमबद्ध किया जाना चाहिए: केवल संख्या वाले पहचानकर्ताओं की संख्या संख्यात्मक रूप से तुलना की जाती है, जिसमें निर्दिष्ट क्रम में अक्षर होते हैं
    ASCII में। न्यूमेरिक आइडेंटिफ़ायर की हमेशा अल्फ़ाबेटिक आइडेंटिफ़ायर से कम प्राथमिकता होती है। उदाहरण: 1.0.0-अल्फा <1.0.0-Alpha.1 <1.0.0-beta.2 <1.0.0-beta.11 <1.0.0-rc.1 <1.0.0-rc.1 + build। 1 <1.0.0 <1.0.0 + 0.3.7 <1.3.7 + बिल्ड <1.3.7 + build.2.b8f12d7 <1.3.7 + build.11.e0f985a।

क्यों अर्थ संस्करण का उपयोग करें?

यह कोई नया या क्रांतिकारी विचार नहीं है। वास्तव में, आपने शायद पहले से ही कुछ ऐसा ही किया था। समस्या यह है कि "समान" पर्याप्त अच्छा नहीं है। कुछ औपचारिक विनिर्देश के बिना, संस्करण संख्या अनिवार्य रूप से निर्भरता प्रबंधन के लिए बेकार है। स्पष्ट और यथोचित लचीली परिभाषाएँ देते हुए,
आप अपने उत्पाद के साथ उपयोगकर्ता सहभागिता की सुविधा प्रदान करते हैं।

एक सरल उदाहरण है जो दर्शाता है कि कैसे अर्थ वर्जनिंग निर्भरता नरक से बचने में आपकी मदद करती है। "Firetruck" नामक एक पुस्तकालय पर विचार करें। उसे लैडर नामक पैकेज की लत है। जब Firetruck बनाया गया था, सीढ़ी संस्करण 3.1.0 था। चूंकि फायरट्रैक 3.1.0 में पेश किए गए विभिन्न तरीकों का उपयोग करता है, आप सीढ़ी को 3.1.0 से अधिक संस्करण में सुरक्षित रूप से अपग्रेड कर सकते हैं, लेकिन 4.0.0 से कम। अब जब लैडर संस्करण 3.1.1 और 3.2.0 उपलब्ध हैं, तो आप उन्हें अपग्रेड कर सकते हैं और जान सकते हैं कि वे मौजूदा सॉफ़्टवेयर के साथ संगत होंगे।

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

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

पूछे जाने वाले प्रश्न

मुझे प्रारंभिक चरण 0.yz पर संस्करण संख्या कैसे बदलनी चाहिए?

सबसे आसान तरीका है कि संस्करण 0.1.0 से शुरू करें और फिर प्रत्येक बाद की रिलीज़ के लिए संस्करण संख्या बढ़ाएं।

कैसे पता लगाने के लिए संस्करण 1.0.0 में अपग्रेड करने का समय है?

यदि आपका उत्पाद अंतिम उपयोगकर्ताओं द्वारा उपयोग किया जाने लगा, तो इसका संस्करण 1.0.0 होना चाहिए। यदि आपके पास एक स्थिर ओपन एपीआई है, तो आपको 1.0.0 में अपग्रेड करना चाहिए। यदि आप पिछड़े संगतता के बारे में चिंतित हैं, तो आपको 1.0.0 में अपग्रेड करना चाहिए।

क्या यह तेजी से विकास और तेजी से चलना बाधित नहीं करता है?

जीरो मेजर वर्जन, बस इतना ही चाहिए। यदि आपका ओपन एपीआई हर दिन बदलता है, तो आपको संस्करण 0.xx में होना चाहिए या अगले मेजर संस्करण पर काम करना चाहिए।

यहां तक ​​कि अगर सबसे छोटे परिवर्तन भी पिछड़े संगत नहीं हैं, तो क्या मैं जल्द ही संस्करण 42.0.0 में होगा?

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

एपीआई प्रलेखन बहुत काम है!

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

यदि मैं गलती से एक मेजर के बजाय एक मामूली संस्करण निर्दिष्ट करता हूं तो मुझे क्या करना चाहिए?

एक बार जब आप समझ जाते हैं कि आपने सिमेंटिक संस्करण को तोड़ दिया है, तो आपको समस्या को ठीक करना चाहिए और एक नया संस्करण जारी करना चाहिए जो समस्या को ठीक करता है और पश्चगामी संगतता को पुनर्स्थापित करता है।

यदि मैं खुले एपीआई को बदले बिना अपने आंतरिक निर्भरता को अद्यतन करता हूं तो मुझे क्या करना चाहिए?

यह स्वीकार्य है अगर यह खुले एपीआई को प्रभावित नहीं करता है। एक उत्पाद जो आपके पैकेज पर स्पष्ट रूप से निर्भर करता है, उसकी अपनी निर्भरता विनिर्देश होनी चाहिए और लेखक एक संघर्ष को नोटिस करेगा।

मैं पुरानी कार्यक्षमता को कैसे चिह्नित करूं?

आउटडेटेड कार्यक्षमता, यह सामान्य है और आगे बढ़ने के लिए अक्सर इसका सहारा लेना पड़ता है। जब आप अपने खुले एपीआई के अप्रचलित भाग को चिह्नित करते हैं, तो आपको दो काम करने होंगे: (1) प्रलेखन को अद्यतन करें, (2) कम से कम एक रिलीज़ को नई और अप्रचलित कार्यक्षमता दोनों का समर्थन करें ताकि उपयोगकर्ता आसानी से पुनर्निर्माण कर सकें।

लेखक के बारे में

शब्दार्थ संस्करण नियंत्रण टॉम प्रेस्टन-वर्नर द्वारा प्रकाशित किया गया है, जो ग्रेवटर के निर्माता और गिटहब के सह-संस्थापक हैं।

अपने प्रश्नों और सुझावों को व्यक्त करने के लिए, GitHub पर एक प्रश्न बनाएं ।

यह अनुवाद गितूब पर

लाइसेंस

क्रिएटिव कॉमन्स - CC बाय 3.0
http://creativecommons.org/licenses/by/3.0/