क्या सिमेंटिक वर्जनिंग संस्करण संख्याओं में 4 घटकों की अनुमति देता है?

Question

सिमेंटिक वर्जनिंग के सभी उदाहरणों को मैंने उपयोग में दिखाने के 3 घटकों को देखा है। 2 से अधिक अवधि वर्ण नहीं। पर $DAYJOB, हम अपनी रिलीज़ संख्या में 4 घटकों का उपयोग करते हैं:

5.0.1.2

क्या शब्दार्थ संस्करण इसके लिए अनुमति देता है?

और एक उच्च-स्तरीय और अधिक तार्किक पक्ष प्रश्न के रूप में, क्या यह वास्तव में भी मायने रखता है? मुझे लगा कि सिमेंटिक वर्जनिंग को लागू करना एक अच्छा विचार हो सकता है, लेकिन आखिरकार पीसीआई जैसी संस्थाएं इसे ओवरराइड करती हैं।

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

Comments

सिमेंटिक संस्करण एक दिशानिर्देश है। कहाँ है पीसीआई राज्य कुछ भी कैसे चीजें हैं के बारे में संस्करणीकृत जा करने के लिए?

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

— void.pointer 13

@ void.pointer आप एक उदाहरण दे सकते हैं कि आप चौथे घटक का उपयोग क्यों कर रहे हैं? क्या आप मूल रूप से आंतरिक लागत और लेखांकन संरचनाओं को बायपास करने के लिए इसका उपयोग कर रहे हैं - अपनी टीम को पैच नंबर को काटे बिना नई सुविधाओं को ट्रैक करने दें?

— एंडरलैंड 13

मूल रूप से @enderland हाँ। MAJOR(PCI).MINOR(PCI).FEATURE.HOTFIX+BUILD। हम मूल रूप से केवल पीसीआई (और बाद में पीसीआई ओवरलोडर्स कंपनी में) को शामिल किए बिना तीसरे और चौथे घटक को बदलने की अनुमति देते हैं। मेरे लिए ऐसा लगता है कि यह थोड़ा विवादित है, मुझे यकीन नहीं है कि वे जिस तरह से संस्करण संख्या का प्रबंधन करते हैं, वे उचित हैं, लेकिन मुझे पीसीआई और ऑडिट प्रक्रिया के बारे में पर्याप्त रूप से नहीं कहना चाहिए।

— void.pointer

हम 4 समूहों का भी उपयोग करते हैं, न कि 3. क्यों? क्योंकि सी ++। सी ++ में द्विआधारी पिछड़ी संगतता और स्रोत पिछड़ी संगतता है: पूर्व का तात्पर्य बाद से है, लेकिन संबंध सममित नहीं है। इस प्रकार, हम बाइनरी संगतता के लिए 4 वें समूह का उपयोग करते हैं (आप सिस्टम को गर्म कर सकते हैं) और स्रोत संगतता के लिए 3 (आपको फिर से संकलन करने की आवश्यकता है, लेकिन आपको अपना कोड संशोधित नहीं करना चाहिए)। और आप जानते हैं कि यह हमारे लिए क्या काम करता है!

— मैथ्यू एम।

Answer 1

ऐसा लगता है कि आप सामान्य सम्मेलनों को दरकिनार कर रहे हैं, बस ओवरहेड / ऑडिट प्रक्रिया से बचने के लिए। बेनाम: कि ... के रूप में मुझे हमला करता है।

क्या आप कर रहे हैं प्रभावी रूप से कुछ हद तक जानबूझकर एक अतिरिक्त संस्करण संख्या (अपने नाबालिग पीसीआई अंकों) बना रही है क्रम में अपने सुविधा ले जाने के लिए / लघु संस्करण संख्याओं को वापस नहीं रह ट्रिगर अपने आंतरिक लेखा परीक्षण के मानदंडों के लिए एक जगह,।

---

वैसे भी, सिमेंटिक वर्जनिंग के बारे में आपके प्रश्न के लिए , सिमेंटिक वर्जनिंग स्टेट्स के लिए युक्ति :

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

• जब आप असंगत एपीआई परिवर्तन करते हैं, तो मुख्य संस्करण
• जब आप बैकवर्ड-संगत तरीके से कार्यक्षमता जोड़ते हैं, तो माइनर संस्करण और
• जब आप पीछे की ओर संगत बग फिक्स करते हैं तो पैटच संस्करण।
• पूर्व-रिलीज़ और बिल्ड मेटाडेटा के लिए अतिरिक्त लेबल MAJOR.MINOR.PATCH प्रारूप के एक्सटेंशन के रूप में उपलब्ध हैं ।

जोर मेरा।

तो सवाल यह है कि, क्या आप प्री-रिलीज़ / बिल्ड मेटाडाटा के लिए चौथे चरित्र का उपयोग कर रहे हैं? या यह मूल रूप से एक और संस्करण संकेत है कि आप जारी कर रहे हैं?

यदि "हाँ" तो सिमेंटिक संस्करण की कल्पना इसके लिए अनुमति देती है। यदि "नहीं" तो आप तकनीकी रूप से शब्दार्थ संस्करण का पालन नहीं कर रहे हैं।

और एक उच्च-स्तरीय और अधिक तार्किक पक्ष प्रश्न के रूप में, क्या यह वास्तव में भी मायने रखता है?

आप इसका कठोरता से पालन करना चाहते हैं या नहीं यह एक निर्णय है जो आपको और आपकी टीम को करना है। सिमेंटिक संस्करण का उद्देश्य एपीआई संगतता के साथ मदद करना है:

बग फिक्स API वर्जन को प्रभावित नहीं करता है पैच वर्जन, बैकवर्ड कम्पैटिबल एपीआई एडिशन / चेंजेस इन माइनर वर्जन, और बैकवर्ड असंगत एपीआई चेंजेज इन द वर्जन वर्जन।

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

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

जब तक आपका एपीआई समान रूप से स्पष्ट है तब तक यह बहुत बड़ी बात नहीं है कि आप किस तरह का चुनाव करते हैं। सिमेंटिक वर्जनिंग बस सीधी होती है, उदाहरण के लिए अगर मैं 3.4.2 का उपयोग कर रहा हूं और 3.4.10 पर अपग्रेड करने की आवश्यकता है, तो मुझे पता है कि मैं कुछ भी किए बिना ऐसा कर सकता हूं। यदि नया संस्करण 3.5.1 है, तो मुझे पता है कि यह पीछे की ओर संगत है। और मुझे पता है कि संस्करण 4.0.1 एक ब्रेकिंग परिवर्तन होगा।

संस्करण संख्या का क्या मतलब है यह सब हिस्सा है।

मूल रूप से @enderland हाँ। प्रमुख (पीसीआई) .MINOR (पीसीआई) .FEATURE.HOTFIX + बनाएँ। हम मूल रूप से केवल PCI और (बाद में PCI कंपनी में पीसीआई अधिपति) को शामिल किए बिना 3 जी और 4 के घटक को बदलने की अनुमति देते हैं। मेरे लिए ऐसा लगता है कि यह थोड़ा विवादित है, मुझे यकीन नहीं है कि वे जिस तरह से संस्करण संख्या का प्रबंधन करते हैं, वे उचित हैं, लेकिन मुझे पीसीआई और ऑडिट प्रक्रिया के बारे में पर्याप्त रूप से नहीं कहना चाहिए।

ठीक है, यह ठीक है। आपके पास एक प्रणाली है जो आपके लिए काम करती है और आपकी आवश्यकताओं को पूरा करती है। यह संस्करण की बात है।

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

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

Comments

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

— void.pointer 15

@ void.pointer मैं यह निर्धारित करने की स्थिति में नहीं हूं कि आपके ऑडिट क्यों / कैसे निर्धारित किए जाते हैं। लेकिन किसी ने फैसला किया कि वे विशिष्ट मानदंडों के आधार पर ऑडिट करना चाहते थे। जानबूझकर कि लेखा परीक्षण के मानदंडों को दरकिनार लगता है (आप कितना पैसा बचाने की परवाह किए बिना ऐसा करके) के विषय में।

— एंडरलैंड

@ void.pointer, एंडरलैंड सही है। यदि आपके संस्करणों को पूरी तरह से वर्णमाला के अक्षरों से नहीं बनाया गया है, तो एक आतंकवादी आपके परिवार को मारने की धमकी देता है, वास्तविक समस्या आतंकवादी है। बेझिझक इसके चारों ओर काम करने के लिए अर्थ वर्जनिंग का पालन न करें (वास्तव में, मैं इस मामले में इसका दृढ़ता से सुझाव दूंगा), लेकिन यह वास्तव में यह है: एक अलग समस्या की आवश्यकता है।

— पॉल ड्रेपर

@PaulDraper वर्जन कब वर्जन के लिए वन ट्रू वे बन गया?

— एंडी

@ और, यह नहीं था। ओपी ने सेमर के बारे में पूछा। IDK क्यों, लेकिन उसने यही किया।

— पॉल ड्रेपर

Answer 2

सिमेंटिक वर्जनिंग के वर्तमान संस्करण में, जो 2.0.0 है , नहीं। एक आवश्यकता है जो संस्करण को एक्सवाईजेड के रूप में परिभाषित करता है जहां एक्स, वाई और जेड गैर-नकारात्मक पूर्णांक हैं जिनमें अग्रणी 0s नहीं हैं:

एक सामान्य संस्करण संख्या में XYZ का फॉर्म लेना होगा जहां X, Y और Z गैर-नकारात्मक पूर्णांक हैं, और MUST में प्रमुख शून्य नहीं हैं। X प्रमुख संस्करण है, Y लघु संस्करण है, और Z पैच संस्करण है। प्रत्येक तत्व संख्यात्मक रूप से बढ़ना चाहिए। उदाहरण के लिए: 1.9.0 -> 1.10.0 -> 1.11.0।

हालाँकि, मेटाडेटा जोड़ने की क्षमता के लिए अनुमति दी गई है:

पैच या पूर्व-रिलीज़ संस्करण के तुरंत बाद प्लस चिह्न और डॉट अलग पहचानकर्ताओं की एक श्रृंखला को जोड़कर मेटाडेटा MAY का निर्माण करें। पहचानकर्ता में केवल ASCII अल्फ़ान्यूमेरिक्स और हाइफ़न शामिल हैं [0-9A-Za-z-]। पहचानकर्ता खाली नहीं होना चाहिए। संस्करण मिसाल का निर्धारण करते समय मेटाडेटा SHOULD को अनदेखा करें। इस प्रकार दो संस्करण जो केवल निर्माण मेटाडेटा में भिन्न होते हैं, उनकी एक ही पूर्वता है। उदाहरण: 1.0.0-Alpha + 001, 1.0.0 + 20130313144700, 1.0.0-beta + exp.sha.5114f85।

हालाँकि, ध्यान देने योग्य कुछ बात यह है कि सिमेंटिक संस्करण विशेष रूप से सॉफ्टवेयर के लिए है जो सार्वजनिक एपीआई घोषित करता है:

सिमेंटिक वर्जनिंग सॉफ्टवेयर का उपयोग करने वाले को सार्वजनिक एपीआई घोषित करना चाहिए। यह एपीआई कोड में ही घोषित किया जा सकता है या प्रलेखन में कड़ाई से मौजूद है। हालांकि यह किया जाता है, यह सटीक और व्यापक होना चाहिए।

यह पुस्तकालयों या सेवाओं के विकास का समर्थन करता है और एक आवेदन स्तर पर नहीं।

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

Comments

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

— void.pointer