Backbone: सेमवेर का पालन करें

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

यदि हम "अर्थपूर्ण" संस्करण का सख्ती से पालन करते हैं, तो यह शायद अब तक Backbone.js 43.0.0 होगा - जो किसी को भी परियोजना की वास्तविक प्रगति का मूल्यांकन करने में मदद नहीं करता है।

इसलिए, जैसा कि मुझे मजाक करना पसंद है - "अर्थात्" संस्करण नहीं, _रोमांटिक संस्करण_।

एक संस्करण संख्या MAJOR.MINOR.PATCH को देखते हुए, बढ़ाएँ:

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

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

लेकिन एपीआई में किसी भी बदलाव से बचना, और "मेजर" रिलीज के तैयार होने की प्रतीक्षा करना प्रगति के लिए एक बहुत बड़ी बाधा होगी। और MAJOR संस्करण संख्या को बार-बार बढ़ाने का विकल्प अविश्वसनीय रूप से अनुपयोगी है।

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

बैकबोन 43.0.0 पर होने में क्या समस्या है?

• क्रोम 32.0.1700 . से भेजा गया

स्पैडगोस @ प्रश्न के लिए +1। संस्करण संख्याएं मनमानी हैं। किसी कारण से, हमारे पास फुर्तीले वेब ऐप्स हैं जो OSes के समान श्रेणी में रखने की कोशिश कर रहे हैं। कई ऐप्स 10 से आगे जाने के बारे में चिंतित हैं ... लेकिन जिन परियोजनाओं (विंडोज़, लिनक्स, आदि) से आप मॉडलिंग कर रहे हैं उनमें से अधिकांश में रिलीज से पहले 1 वर्ष/बहु-वर्षीय देव चक्र हैं, इसलिए 1.x -> 2.x एक बड़ी बात है। एक चुस्त परियोजना बहुत तेज़ी से आगे बढ़ती है, तेज़ी से बढ़ने से भी समझ में आता है।

मैं इसके पीछे के तर्क से भी असहमत हूं।

मैरियनेट अभी v1.2.3 पर है, और सख्त सिमेंटिक वर्जनिंग का पालन करने की पूरी कोशिश कर रहा है। अब तक, हमारे पास कोई समस्या नहीं है, भले ही हम "सभी सतह क्षेत्र" भी हैं। हमने नई सुविधाएँ जोड़ी हैं। हमने बग ठीक कर दिए हैं। लेकिन v1.0 अभी भी v1.2.3.1 के साथ संगत है। हमने v2 रिलीज़ के लिए टिकटों को तब स्थगित कर दिया है जब वे एपीआई या अपेक्षित व्यवहार तोड़ने वाले परिवर्तन हैं।

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

जैसा कि यह खड़ा है, एक v1.1 रिलीज में संगतता को तोड़ने से प्लगइन और ऐड-ऑन डेवलपर्स के लिए बहुत दर्द होता है, जैसे मैरियनेटजेएस टीम। हमें अपने कोड में पैच के साथ व्यवहार को वापस भरना पड़ा, ताकि हम v1.0 और v1.1 दोनों के लिए व्यवहार्य बने रह सकें ... यह एक मजेदार स्थिति नहीं है। बैकबोन जैसी कोर लाइब्रेरी के ब्रेकिंग चेंजेस के रिपल इफेक्ट बहुत बड़े हैं ... यह सिर्फ बैकबोन नहीं है जो प्रभावित होता है।

मैं मानता हूं कि यह "नहीं कर सकता" के बजाय "नहीं करना चाहता" के मामले की तरह लगता है। ब्रेकिंग परिवर्तन जैसे कि https://github.com/jashkenas/backbone/pull/2461 में तात्कालिकता का कोई वास्तविक अर्थ नहीं है, और यदि आप 43.0.1 समस्या नहीं चाहते हैं तो एक प्रमुख संस्करण अपडेट की प्रतीक्षा कर सकते हैं।

मेरे लिए, बैकबोन के साथ सेवर (अन्य बातों के अलावा) का सम्मान नहीं करने की सबसे बड़ी समस्या बैकबोन को पढ़ाने और प्रचार करने में है। छात्रों या संभावित ग्राहकों के समूह को यह बताना अच्छा नहीं है कि आपके स्टैक में सब कुछ एक निश्चित तरीके से काम करने वाला है... बैकबोन को छोड़कर।

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

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

@jashkenas हम हमेशा तीसरे अंक को .0 पर छोड़ सकते हैं :)

यह संभवत: हम जो अभी कर रहे हैं, उससे थोड़ा करीब सेमवर के लिए शब्दार्थ रूप से मैप करेंगे। हो सकता है कि यह कुछ निष्क्रिय-आक्रामक क्रिप्टो-राजनीतिक कटाक्षों पर टैंप कर दे कि कैसे यह तकनीकी रूप से गलत है कि सेमवर का पालन न करें।

मुझे लगता है कि बॉब की बात सही है कि यह स्पष्ट रूप से स्पष्ट करना अधिक महत्वपूर्ण है कि हम किस प्रणाली का अनुसरण करते हैं, चाहे हम किसी भी प्रणाली का पालन करें।

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

:+1: सेवर के लिए। मुझे मुख्य रूप से किसी दिए गए सॉफ़्टवेयर के संस्करण में उसकी प्रगति के सूचकांक के रूप में नहीं बल्कि इसकी संगतता के रूप में दिलचस्पी है।

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

यह जानना कि बैकबोन (या जो कुछ भी) 2.4.3 पर है, इसका मतलब इसकी विशेषताओं के मामले में कुछ भी नहीं है। हालांकि, इसका मतलब यह है कि मैं अपने 2.0.4 से बिना कुछ तोड़े अपग्रेड कर सकता हूं।

यदि हम "अर्थपूर्ण" संस्करण का सख्ती से पालन करते हैं, तो यह शायद अब तक Backbone.js 43.0.0 होगा - जो किसी को भी परियोजना की वास्तविक प्रगति का मूल्यांकन करने में मदद नहीं करता है।

एक बहुत ही मामूली/शायद अस्तित्वहीन समस्या। सीवर का पालन नहीं कर रहे हैं? बड़ी समस्या।

:+1:, इतने बड़े प्रोजेक्ट के लिए सेवर जरूरी है।

मैं @knowtheory के साथ हूं। 43.0.0 थोड़ा अजीब लग रहा है लेकिन मुझे लगता है कि 1.43.0 ठीक रहेगा और npm install बाद किसी को भी आश्चर्यजनक ब्रेकेज नहीं मिलेगा।

संस्करण संख्या उच्च होने की परवाह कौन करता है?
यह एक मानक है, यदि आप इसका उपयोग कर सकते हैं, तो आपको इसका उपयोग करना चाहिए।
मुझे यह भी समझ नहीं आता कि यह चर्चा इतनी लंबी क्यों चल रही है।

:+1: इसने #2996 और #2997 में कुछ मुद्दों को रोका होगा, और अन्य बैकबोन रिलीज के साथ अन्य समस्याओं को रोका होगा।

@braddunbar कि (और बाकी के कारण "खिलाफ") ऐसा लगता है कि यह संस्करण संख्या के सौंदर्यशास्त्र को उसके वास्तविक अर्थ से अधिक महत्व दे रहा है।

धन्यवाद, लेकिन "अर्थात्" संस्करण का सख्ती से पालन करने से बैकबोन के लिए बहुत अच्छा काम नहीं होगा।

मुझे लगता है कि यह बैकबोन अपने उपयोगकर्ताओं (निर्भरता प्रबंधन के साथ) के लिए अच्छी तरह से काम करने के बारे में अधिक है। निम्न में से कौन सा सेमर गारंटी देगा...

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

+1 @ डेरिकबेली

एक उदाहरण के रूप में ये 1.1.0 के बाद से हैं, पैच रिलीज के पीछे विचार यह है कि इन सुधारों की बिल्कुल भी आवश्यकता नहीं होनी चाहिए।

https://github.com/marionettejs/backbone.marionette/commit/5a498d250d23a68c9c84a1362782edcf8774a1c8

https://github.com/marionettejs/backbone.marionette/commit/baed36bad8357e4379d4d2bc0460fd1375d2c85b

https://github.com/marionettejs/backbone.marionette/commit/e13e912bdda8e056c0e7b5e15d127eff158a48cb#diff -3c2771f47bdfe073ea95bfa54a37a972R167

एनपीएम या बोवर में पैकेज के लिए, यह बहस के लिए भी नहीं है।

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

सवाल यह नहीं है, "क्या हमें सेवर का इस्तेमाल करना चाहिए?" सवाल है, "क्या हम पारिस्थितिकी तंत्र में अच्छे नागरिक बनना चाहते हैं?"

यदि उत्तर नहीं है, तो इसका जोर से और स्पष्ट रूप से विज्ञापन किया जाना चाहिए, क्योंकि एपीआई अनुबंध का पालन करने वाले किसी भी अन्य पैकेज की तरह अपने पैकेज को स्थापित करना सुरक्षित नहीं है।

जब आप एनपीएम या बोवर के साथ एक पैकेज प्रकाशित करते हैं, तो सेवर आपके द्वारा दर्ज किए गए एपीआई अनुबंध का हिस्सा होता है।

नहीं यह नहीं। npm install --save [email protected] एक कठिन आवश्यकता नहीं है।

@ akre54 मुझे @jashkenas के विचारों को जानता

@ akre54 हाँ, यह है। npm मानता है कि रिपॉजिटरी के सभी पैकेज semver का अनुसरण करते हैं । इस प्रकार यह निर्धारित करता है कि कौन से पैकेज किसके साथ संगत हैं।

package.json दस्तावेज़ से:

"संस्करण नोड-सेवर द्वारा पार्स करने योग्य होना चाहिए, जो एक निर्भरता के रूप में एनपीएम के साथ बंडल किया गया है। (एनपीएम इसे स्वयं उपयोग करने के लिए सेवर स्थापित करें।)"

यदि आपका संस्करण संख्या _lie_ जब उन्हें सेवर के रूप में व्याख्यायित किया जाता है, तो यह सही पार्सिंग नहीं है। इस प्रकार, आप package.json अनुबंध को तोड़ रहे हैं, और आप npm पारिस्थितिकी तंत्र में पैकेज संस्करणों का उपयोग करने वाले लोगों के साथ संगतता को तोड़ रहे हैं।

यह सिर्फ व्यक्तिगत पसंद की बात नहीं है। यह पैकेज इंटरऑपरेबिलिटी की बात है।

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

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

npm install --save [email protected] एक कठिन आवश्यकता नहीं है।

यह जानते हुए कि एक पूर्ण विकसित एप्लिकेशन में जाने वाले हजारों पैकेजों में से आपको _is_ के साथ ऐसा करना होगा जो एक कठिन आवश्यकता है। उपयोगकर्ताओं को अपने सभी पैकेजों के संस्करणों को कसकर बंद करने के लिए मजबूर करना क्योंकि कुछ मॉड्यूल नियमों का पालन नहीं करते हैं _is_ एक कठिन आवश्यकता है, क्योंकि यह बग फिक्स, सुरक्षा पैच इत्यादि को बनाए रखने के मामले को जटिल बनाता है ...

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

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

मुझे लगता है कि यहां सीखा गया सबक है "पैकेज.जेसन के माध्यम से बैकबोन में खींचते समय ~ या ^ उपयोग न करें"

@ akre54 मुझे सेवर के बारे में आपके दृष्टिकोण में दिलचस्पी है

आम तौर पर मैं यहां तर्कों से सहमत हूं, लेकिन मुझे आश्चर्य है कि प्रमुख संस्करण को टक्कर देना _every_ ब्रेकिंग परिवर्तन पर कार्रवाई का सबसे अच्छा तरीका है (और फिर, अंडरस्कोर अधिकतर सतह क्षेत्र होने के साथ, यह _a बहुत_ है)। अंडरस्कोर का उपयोग तृतीय-पक्ष पुस्तकालयों के एक बड़े सौदे में किया जाता है, और उन सभी को विशाल संस्करणों के साथ बनाए रखने की आवश्यकता कठिन और खतरनाक होगी। (क्या आज जारी किया गया पैकेज अंडरस्कोर पर संस्करण 2 तक निर्भर होना चाहिए? 1.7? 1.6.x? क्या इसे अपनी निर्भरता को मुख्य परियोजना से अलग अंडरस्कोर की आवश्यकता की कीमत पर पिन करना चाहिए?)

मुझे लगता है कि यहां सीखा गया सबक है "पैकेज.जेसन के माध्यम से बैकबोन में खींचते समय ~ या ^ का उपयोग न करें"

हां।

मुझे लगता है कि यहां सीखा गया सबक है "पैकेज.जेसन के माध्यम से बैकबोन में खींचते समय ~ या ^ का उपयोग न करें"

मैंने ऊपर उल्लिखित किया है कि यह टेकअवे सबक क्यों नहीं होना चाहिए।

मुझे लगता है कि यहां सीखा गया सबक है "पैकेज.जेसन के माध्यम से बैकबोन में खींचते समय ~ या ^ का उपयोग न करें"

परिणामस्वरूप, आप अपने कोड को टूटने से बचाने के लिए यही करते हैं।

सबक कुछ इस तरह होगा "निम्न सेवर सभी के लिए अच्छा है, ऐसा नहीं करना नहीं है।"

मैं "रोमांटिक" संस्करण में मूल्य की सराहना कर सकता हूं। बहुत बुरा वे बहुत अच्छी तरह से सह-अस्तित्व में नहीं हैं।

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

चीजों को न तोड़ने के बारे में कम से कम बैकबोन आमतौर पर बहुत अच्छा होता है।

@dgbeck चीजें प्रति संस्करण हर समय

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

मेरे लिए यह एक महान मूल्य वर्धित है लेकिन जाहिर है कि यह अनुरक्षक के लिए जटिलता की कीमत पर आता है।