क्या मुझे अपने मॉड्यूल को मैन्युअल रूप से देखने की आवश्यकता है हर बार जब मैं कोर मैगेंटो कोड के एक टुकड़े का उपयोग करता हूं और एक आवश्यकता जोड़ देता हूं: ... संगीतकार ।जॉन को लाइन?
हां, आपके कोड में हर बार आप किसी भी कोर मॉड्यूल से किसी भी चीज का उपयोग करते हैं, जिसे आपको अपने संगीतकार की आवश्यकता में जोड़ना होता है। जैसा कि आप की संभावना है कि आपका लोड ऑर्डर कोर मॉड्यूल के बाद होना चाहिए, मैं इसे module.xmlअनुक्रम खंड में आपकी फ़ाइल में जोड़ने का भी सुझाव दूंगा ।
या कोई स्वचालित उपकरण है जो मेरे लिए ऐसा कर सकता है?
मैं अभी तक किसी के सामने नहीं आया हूं। अगर वहाँ है तो कृपया मुझे बताएं। यह एक बहुत ही परिष्कृत उपकरण होने की आवश्यकता होगी और इसके लिए पर्याप्त परीक्षण कवरेज की आवश्यकता होगी और फिर एक काम सेट का उत्पादन करने के लिए विभिन्न संस्करणों का एक मैट्रिक्स चलाता है।
मैं अपने कंपोज़र.जसन में शामिल करने के लिए संस्करण कैसे निर्दिष्ट करूं? यह विशिष्ट मॉड्यूल संस्करण होना चाहिए जिसे मैंने विकसित किया है? या मुझे कुछ प्रकार के वाइल्डकार्ड शामिल करना चाहिए? या मुझे ट्रेडऑफ के आधार पर निर्णय लेने की आवश्यकता है? यदि हां, तो संस्करण निर्दिष्ट करने की प्रत्येक शैली के लिए ट्रेडऑफ़्स क्या शामिल हैं?
एक संस्करण संख्या को परिभाषित करने के लिए विकल्प
100.0.2
केवल तभी काम करें जब यह विशिष्ट संस्करण हो
100.0.*
*एक वाइल्डकार्ड है और किसी भी संस्करण संख्या के साथ बदला जा सकता है
100.0.0, 100.0.1, ...,100.0.120
~100.0.2
बनाता है 2 एक वाइल्डकार्ड है कि केवल इतने तक जा सकता है 100.0.2, 100.0.3, ...,100.0.120
^100.0.2
किसी भी 101 तक जारी की अनुमति देता है तो 100.0.2, 100.0.3, ..., 100.1.0,100.2.5
2-4 विकल्पों के लिए यदि आपकी स्थिरता सेटिंग्स इसकी अनुमति देती हैं तो इसमें संस्करण भी शामिल होंगे 100.0.1-beta
प्रायोगिक उपयोग
विकल्प 1.) सबसे सतर्क है, आप जानते हैं कि आपने किस संस्करण के खिलाफ विकास किया है और केवल इस विशेष संस्करण के साथ काम करना स्वीकार करते हैं - आपका मॉड्यूल केवल उस संस्करण में उस विशेष मॉड्यूल के साथ स्थापित किया जा सकता है। अन्य सभी इंस्टॉल / अपग्रेड प्रयास एक कंपोजर संदेश के साथ विफल होंगे जो यह दर्शाते हैं कि यह घटकों का एक इंस्टॉल करने योग्य सेट नहीं पा सकता है।
विकल्प 2.) मुझे लगता है कि विकल्प 3 के रूप में गैर-विकल्प के रूप में सोचा जा सकता है। यदि आप इसे पसंद करते हैं ~100.0.0
विकल्प 3.) तब तक संगत रहें जब तक कि कोई नई सुविधाएँ पेश न की जाएं
विकल्प 4.) तब तक संगत रहें जब तक कोई ब्रेकिंग परिवर्तन नहीं लाया जाता है
व्यापार बंद
1 आपका एक्सटेंशन केवल एक Magento मॉड्यूल के 1 संस्करण के लिए काम करता है (तकनीकी रूप से अगर किसी मॉड्यूल में कोई परिवर्तन नहीं हैं तो संस्करण संख्या में वृद्धि नहीं होनी चाहिए और कई Magento प्रोजेक्ट संस्करण सैद्धांतिक रूप से समान संस्करण के साथ समान Magento कोर मॉड्यूल शामिल कर सकते हैं। व्यावहारिक रूप से I यह नहीं देखा है और ऐसा लगता है कि यह Magento के अंत में यहाँ देखने के लिए कुछ प्रक्रिया परिवर्तन की आवश्यकता है)। चूँकि आप Magento के कोर मॉड्यूल के 1 संस्करण के साथ इतने निकट से बंधे हैं कि आप बहुत सारे रिलीज़ और अपने स्वयं के एक्सटेंशन के संस्करणों के साथ समाप्त हो जाते हैं, यदि आप संगत रहना चाहते हैं।
3-4 आपका एक्सटेंशन Magento के कई संस्करणों के साथ काम करता है और आपको हर बार Magento का नया संस्करण जारी करते समय अपने एक्सटेंशन के विभिन्न संस्करणों को रिलीज़ करने की आवश्यकता नहीं है। यहाँ नकारात्मक पक्ष यह है कि आप संगतता का दावा करते हैं भले ही एक बदलाव मैजेंटो में पेश किया जा सकता है जो आपके अपने कोड के साथ असंगत है। यह जोखिम वास्तविक है क्योंकि मैगेंटो की अपने स्वयं के मॉड्यूल रिलीज के लिए अर्थ वर्जनिंग की परिभाषा केवल इसके सीमित दायरे के साथ @apiएनोटेशन (इस गिटहब मुद्दे पर इस पर अधिक ) के साथ चिह्नित है ।
tl; डॉ;
100.0.2इसे सुरक्षित रखें, आपके लिए बनाए रखने के लिए बहुत सारे रिलीज़,
^100.0.2सिमेंटिक वर्जनिंग यह कैसे काम करना चाहिए, आपके लिए कम रिलीज़ करता है, लेकिन वर्तमान में @apiएनोटेट वर्गों और विधियों के सीमित दायरे के कारण उच्च जोखिम के साथ । यदि आपके पास एक एक्सटेंशन था जो स्वीकृत वर्गों और विधियों का उपयोग करके 100% है तो यह स्पष्ट विकल्प होगा।