PHP 7.4 जारी! कैसे अपग्रेड होता है

आज, आखिरकार, PHP 7.4 की रिलीज प्रकाशित हुई है!


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

खराब (या अच्छा?) समाचार - PHP 7.4 की रिहाई के साथ, PHP 7.2 के लिए सक्रिय समर्थन बंद हो जाता है । उनकी नवीनतम रिलीज़ दिसंबर के मध्य में होने वाली है। हम लंबे समय से PHP 7.4 के साथ प्रयोग कर रहे हैं, और हाल ही में हम सक्रिय रूप से इसके संक्रमण में लगे हुए हैं, क्योंकि अब हम लगभग असमर्थित संस्करण 7.2 पर हैं।

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

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

यदि बहुत सरल किया जाए, तो हम कई चरणों को अलग कर सकते हैं:

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

PHP रिपॉजिटरी में हमारा संपादन

प्रीलोड की समस्या ( फिक्स )

इस बार, इस प्रक्रिया में कुछ बदल गया है: चूंकि हम प्रीलोड की प्रतीक्षा कर रहे थे, हमने जुलाई में काम का हिस्सा वापस लेना शुरू कर दिया था, संस्करण 7.4.0beta1 के दौरान। नतीजतन, यह हमारे लिए डिबगिंग पर खर्च किए गए समय की एक बड़ी मात्रा में हुआ, क्योंकि PHP 7.4 तब पूरी तरह से कच्चा था। लेकिन दूसरी ओर, परिणामस्वरूप, हमने एक अप्रिय बग पाया, इसे ठीक किया और ऊपर की तरफ तय किया, जिससे पूरे समुदाय को मदद मिली।

फिर यह परीक्षण करने का समय है।

निजी संपत्तियों तक पहुंच की समस्या ( फिक्स )

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

जब हम परीक्षण चलाने में सफल हुए, तब हमने एक बहुत ही अजीब बात देखी। निम्नलिखित त्रुटि के साथ कई दुर्घटनाएँ हुई हैं:

PHP Fatal error: Cannot access private property ClassLoader::$classMap in vendor/composer/ClassLoader.php 

किसी वर्ग की निजी संपत्ति तक पहुंच केवल उसके अंदर ही होती है, लेकिन PHP एक त्रुटि की रिपोर्ट करता है: आप निजी संपत्ति तक पहुंच नहीं सकते हैं जैसे कि कॉल किसी अन्य वर्ग से आया था।

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

हमने एक न्यूनतम प्रजनन मामले को पाया (जो, एक पल के लिए, तीन वर्गों, एक ऑटोलैडर और परावर्तन की आवश्यकता होती है), समस्या का कारण तय किया और इसे अपस्ट्रीम में ठीक करना शुरू कर दिया , यह पता चला कि यह समस्या PHP 7.3 (सबसे अधिक संभावना) के साथ मौजूद है इस बदलाव के बाद), पूरी दुनिया उसके साथ एक साल तक रही और उसने हमारे सामने किसी को परेशान नहीं किया।

सगाई कोड असंगतता नियम

अब हम PHP 7.4 के साथ अपने कोड की सभी असंगतताओं को ठीक कर रहे हैं। हमारे लिए अधिकांश असंगतताएँ (सौ से अधिक स्थानों पर, सभी असंगतताओं का 80% से अधिक) त्रुटि "अतिरिक्त अशक्त / बूल / इंट के मूल्य पर सरणी ऑफसेट तक पहुँचने की कोशिश" (आरपीएफसी के अनुरूप ) के अतिरिक्त के कारण हुई। यह तब होता है जब अन्य डेटा प्रकारों पर किसी सरणी तत्व तक पहुंचने के सिंटैक्स का उपयोग किया जाता है।

निम्नलिखित उदाहरण अच्छी तरह से समस्या का चित्रण करता है:

 $a = false; var_dump($a['somekey']); // PHP 7.3: // NULL // // PHP 7.4: // Notice: Trying to access array offset on value of type bool in Command line code on line 1 // NULL 

ऑफहैंड ऐसा लगता है कि यह वास्तविक कोड में नहीं होना चाहिए, लेकिन, जैसा कि अभ्यास ने दिखाया है, यह एक काफी सामान्य मामला है: उदाहरण के लिए, एक फ़ंक्शन सामान्य मामले में एक सरणी वापस कर सकता है और एक त्रुटि के मामले में गलत / अशक्त हो सकता है, और आगे चलकर गलत / अशक्त के बारे में ढेर हो सकता है। खो गया है, और इस मामले को अलग से संभाला नहीं है।

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

सामने आई समस्याओं के संदर्भ में दूसरा अपडेट तरीका_एक्सिस्ट्स () के काम करने के तरीके में बदलाव है। वैसे, फ़िलहाल रिलीज़ नोट्स या अपग्रेड गाइड में इसके बारे में कोई जानकारी नहीं है। इसका सार इस प्रकार है:

 class A1 {    private function priv() {} } class B1 extends A1 {} var_dump(method_exists(B1::class, 'priv')); // PHP 7.3: bool(true) // PHP 7.4: bool(false) 

यह सुविधा, वास्तविक कोड में फिर से आना मुश्किल है। लेकिन, जैसा कि यह निकला, हमने अनायास ही परीक्षणों में इसका सक्रिय रूप से शोषण किया।

बेशक, हम अन्य असंगतियों के साथ अलग-अलग डिग्री के साथ सामना कर रहे हैं, जिसमें प्रतिबिंब से संबंधित कई बदलाव ( उदाहरण एक , उदाहरण दो ), हेक्सडेक में परिवर्तन () और इसी तरह, ArrayAccess ऑब्जेक्ट्स के साथ भी array_key_exists () का निषेध , के साथ संगीतकार के माध्यम से जुड़े विभिन्न निर्भरता पुस्तकालयों में असंगतियां, और यहां तक ​​कि सभी प्रकार की विदेशी चीजों के साथ, जैसे कि stream_set_option () जो कि धारा के रैपर के लिए अनिवार्य हो गए। लेकिन संक्षेप में, गैर-सरणियों पर सरणियों के सिंटैक्स का उपयोग करने के मामले में इन सभी परिवर्तनों के पालन की लागत की तुलना नहीं की जा सकती है।

फिलहाल, हमने यूनिट परीक्षणों के साथ काम करना समाप्त कर दिया है: वे पूरी तरह से PHP 7.4 में पास होते हैं। हम एपीआई परीक्षणों पर काम कर रहे हैं और वर्ष के अंत तक विभिन्न समूहों और वातावरणों को बदलना शुरू कर रहे हैं।

मैं आपको चर्चा के लिए इस चर्चा में आमंत्रित करना चाहता हूं: क्या आपने पहले ही PHP 7.4 की कोशिश की है? यदि हां, तो आपका अनुभव कैसा था? क्या आप पार करने जा रहे हैं?