बग रिपोर्ट के 7 दिन बाद पीआर मर्ज किए जाने पर भी 7049 को रोल आउट होने में 1 महीने से अधिक का समय लगा

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

उम्मीद है कि टीम के पास पीआर + रिलीज प्रक्रिया के आसपास की कुछ बाधाओं को दूर करने की योजना है।

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

और उस पर गौर करें, एक उच्च-दृश्यता मुद्दे में उल्लेख किए जाने के बाद, Xamarin.Forms टीम के किसी व्यक्ति ने अंततः https://github.com/xamarin/Xamarin.Forms/pull/7728 को जवाब दिया

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

और उस पर गौर करें, एक उच्च-दृश्यता मुद्दे में उल्लेख किए जाने के बाद, Xamarin.Forms टीम पर किसी ने अंततः xamarin/Xamarin.Forms#7728 का जवाब दिया।

मुझे टीम के साथ सहानुभूति है। कि कई मुद्दों का प्रबंधन/प्रबंधन/ठीक करना आसान नहीं है। कहा जा रहा है कि, निश्चित रूप से बाधाओं को दूर करने और खुले मुद्दों और पीआर को कम करने पर ध्यान देने की आवश्यकता है।

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

मुझे कुछ संबंधित बिंदु दिखाई दे रहे हैं

१) मैं नहीं जानता कि कितने लोग फ़ॉर्म पर काम करते हैं, लेकिन मुझे ऐसा लगता है कि नई बग या पीआर की तेज़ी से बढ़ती गति के साथ टीम बहुत छोटी है। यह केवल बदतर होता जा रहा है क्योंकि उन्हें फॉर्म और माउ के बीच ध्यान बांटना होगा। मुझे वास्तव में उम्मीद है कि टीम को जल्द ही काफी बढ़ावा मिलेगा।

2) यह वास्तव में मदद करेगा यदि माइक्रोसॉफ्ट वास्तव में अपने स्वयं के ऐप्स पर फॉर्म का उपयोग करना शुरू कर दे। और मेरा मतलब साधारण डेमो या कॉन्फ़्रेंस ऐप्स से नहीं है। मेरा मतलब है टीम्स या आउटलुक जैसे असली ऐप। मुझे खुशी होगी अगर मैं इस पर गलत हूं लेकिन मुझे स्टोर पर कोई एमएस फॉर्म ऐप नहीं मिला और इस ट्वीट जैसे कुछ स्रोत के अनुसार https://twitter.com/safaiyeh/status/1219294459298344961 वे ज्यादातर प्रतिक्रिया का उपयोग करते हैं मूल निवासी।

• यह वास्तव में एक अच्छा संकेत नहीं भेजता है क्योंकि यदि एमएस अपनी तकनीक (एक्सएफ) का उपयोग नहीं करता है तो हमें क्यों करना चाहिए?

• जटिल ऐप्स पर आंतरिक रूप से फ़ॉर्म का उपयोग करना परीक्षण की अतिरिक्त परत हो सकती है और सार्वजनिक रिलीज़ को प्रभावित करने वाली समस्याओं की संख्या को कम कर सकती है। साथ ही वे देख सकते थे कि फ़ॉर्म के साथ काम करना उतना आसान नहीं है जितना वे हमें बता रहे हैं

3) मुझे इस तथ्य में एक और समस्या दिखाई देती है कि एमएस लगातार पहले से सिद्ध और मौजूदा समाधानों जैसे विन यूआई एक्सएएमएल का उपयोग करने के बजाय एक्सएफ एक्सएएमएल के रूप में पहिया को फिर से शुरू करने का प्रयास करता है। उन्हें पहले से मौजूद सुविधाओं को विकसित करने और उसके कारण पेश किए गए बग को ठीक करने में समय लगाना पड़ता है और फिर अन्य सुविधाओं और बग फिक्स के लिए कम समय होता है।

मैं @Reveon . के साथ 100% सहमत हूं
ओह, और मुझे यह कहना है कि Xamarin के साथ Windows के लिए VisualStudio का उपयोग करना एक अति-निराशाजनक अनुभव है।

वे बकाया, अवरुद्ध, बग जोड़ते रहते हैं ... मुझे यह भी नहीं पता कि यह कैसे संभव है (सभी आईओएस डिवाइस को तोड़ना, प्रावधान प्रोफाइल तोड़ना, इशारा पहचानकर्ता तोड़ना जैसी चीजें ... इस तरह की बग उत्पादन में कैसे जा सकती हैं और फिर रिलीज बिल्ड में तय होने में हफ्तों या महीनों का समय लगता है? पता नहीं ....)

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

मुझे यकीन है कि एमएयूआई के साथ ऐसी चीजें बदल जाएंगी, और जल्दी या बाद में माइक्रोसॉफ्ट गंभीर परियोजनाओं के लिए आंतरिक रूप से एमएयूआई का उपयोग करना शुरू कर देगा

एक और प्रशंसापत्र:
https://github.com/xamarin/Xamarin.Forms/issues/10482#issuecomment -633730446
@EmilAlipiev :

मैं इस मुद्दे के लिए 1.5 महीने से अपने पीआर के विलय का इंतजार कर रहा हूं। आईओएस और एंड्रॉइड के लिए पहले से ही मौजूदा मुद्दा जुलाई 2019 में तय किया गया था और यूडब्ल्यूपी के लिए किसी ने भी छुआ नहीं था। मैंने अप्रैल में तय किया और समीक्षा और विलय के लिए कई बार अनुरोध किया। यह वास्तव में कष्टप्रद है कि xamarin टीमें कैसे काम कर रही हैं। आप देख सकते हैं कि वे प्रति दिन केवल 1-2 पीआर की समीक्षा करते हैं।
#10316

हालाँकि मैं अक्सर निराश होता हूँ, "ज़ामरीन छोटी गाड़ी है" कठोर कथन है। 2000+ खुले मुद्दे आज, यदि आप जाँचते हैं कि स्पंदन में 5000+ खुले मुद्दे हैं। संख्याएं इतनी महत्वपूर्ण नहीं हैं। Xamarin.forms uwp (xbox सहित), wpf, mac, gtk, tizen जैसे अन्य क्रॉस प्लेटफ़ॉर्म से अधिक ऑफ़र करता है। तो उदाहरण के लिए डब्ल्यूपीएफ के लिए कई खुले मुद्दे हैं जो हम में से अधिकांश के लिए कम प्राथमिकता है।
Xamarin.forms का मूल ios, android और uwp होना चाहिए, हालांकि Xamarin टीम अक्सर uwp की उपेक्षा करती है।

1. लेआउट, सूचीदृश्य, हिंडोला, संग्रह दृश्य, चित्र, मानचित्र, लेबल, संपादक आदि जैसे मुख्य तत्व होने चाहिए। वे बग मुक्त होने चाहिए। यदि आप उन पर कोई नई रिलीज़ या अपडेट करते हैं, तो आपको यह सुनिश्चित करना होगा कि कोई शोस्टॉपर बग नहीं है। यदि कोई बग है, तो आपको इसे अधिकतम एक सप्ताह के भीतर हल करना होगा। लेकिन ज़ामरीन टीम उस शांत "4.5-4.6" को शानदार सुविधाओं के साथ रिलीज़ कर रही है (जिन्हें इस फैंसी टूल की 10% समुदाय की आवश्यकता है?) और छवि नियंत्रण टूट गया है। मार्च की शुरुआत में समस्या की सूचना दी गई थी और आज तक हल नहीं हुई है। वही "मूल असेंबली में बंडल" टूटा हुआ है। उन महत्वपूर्ण कारणों से मैं 4.5 और 4.6 में अपग्रेड नहीं कर सकता। वे 4.7 नई सुविधाओं को जोड़ने के साथ विकसित होते रहते हैं। मैं और हम में से अधिकांश रिलीज नोट्स पर नजर रखते हैं कि क्या हमारे बग हल हो गए हैं, मैं अब यह भी नहीं पढ़ता कि कौन सी सुविधा जोड़ी गई थी।
2. Xamarin टीम को यह समझना होगा। बहुत से लोग Xamarin को चुनने का सबसे बड़ा कारण "UWP" है। मैं फ्रीलांसर हूं। मैं अपने ग्राहक से पूछता हूं कि क्यों न फड़फड़ाया जाए या देशी प्रतिक्रिया न दी जाए? वह कहते हैं क्योंकि ज़ामरीन के पास UWP है। मुझे यूडब्ल्यूपी भी चाहिए। लेकिन Uwp ज्यादातर Xamarin.forms के साथ छोटी गाड़ी है। उन्होंने कलेक्शन व्यू पेश किया, यह वास्तव में बहुत अच्छा है लेकिन एक साल से यह बग हल नहीं हुआ है। मैंने इसे ठीक कर दिया है, कोई समीक्षा नहीं कर रहा है। मैं कोई और योगदान करने से हतोत्साहित था।
3. हॉटरेलोड बिल्कुल भी काम नहीं कर रहा है। मैंने चहचहाना पर सभी "चुंबन चुंबन" पढ़ा है कि हॉटरीलोड कितना अच्छा है। मैं सोच रहा हूं कि मेरे साथ कुछ गड़बड़ होनी चाहिए या वे किसी अन्य उपकरण का उपयोग करते हैं। क्योंकि अक्सर हॉटरेलोड अपडेट नहीं हो रहा है। मैं अभी भी तृतीय पक्ष टूल जैसे livexaml आदि का उपयोग कर रहा हूं। मैंने अपना खुद का हॉटरेलोड करने के लिए एक साधारण कंसोल एप्लिकेशन भी बनाया है। यह मुझे 1 दिन खर्च करता है। Xamarin की तुलना में बहुत बेहतर काम करता है और यहां तक ​​कि uwp के लिए भी काम करता है। वे इसे कैसे नहीं पहुंचा सकते? उनके पास लिवरलोड काम कर रहा था।

4. सबसे महत्वपूर्ण बिंदु; @Reveon ने क्या उल्लेख किया है। उन्हें एक वास्तविक एंटरप्राइज़ एप्लिकेशन की आवश्यकता होती है जो xamarin.forms के साथ काम करता है और उन्हें वास्तविक मुद्दों का पता लगाने के लिए इसे नई रिलीज़ के साथ अपडेट करना चाहिए। वे शिकायत करते हैं कि "रेप्रो देना इतना कठिन नहीं है"। हां, यह बहुत कठिन है यदि यह समस्या केवल आपके एंटरप्राइज़ एप्लिकेशन पर होती है, न कि टूडू ऐप पर। आपको उसी ui को दोहराने की कोशिश करनी होगी। जब तक आप इसका पता नहीं लगा लेते, तब तक इसमें आपके दिन लग सकते हैं। इसलिए यह बहुत महत्वपूर्ण है कि कोई ऐसा व्यक्ति होना चाहिए जिसके पास एक बड़ा आवेदन हो। मैं वास्तव में सोच रहा हूं कि क्या उन ज़ामरीन देवों में से कोई भी जो हम चिकोटी, यूट्यूब, ट्विटर आदि पर देखते हैं, क्या उन्होंने कभी xamarin.forms के साथ एक बड़ा एप्लिकेशन विकसित किया है।

5. मुझे कुछ स्वीकार करना होगा, हालांकि मुझे गैर-ओपन सोर्स टूल्स का उपयोग करना पसंद नहीं है, मेरे 50% से अधिक ऐप्स सिंकफ्यूजन टूल के साथ हैं। सिंकफ्यूजन के बिना, मुझे लगता है कि एंटरप्राइज़ वर्किंग एप्लिकेशन प्राप्त करना बहुत कठिन है। उनके पास वह सब कुछ है जो xamarin नहीं करता है या xamarin छोटी गाड़ी क्या है। उदाहरण के लिए, मैंने ड्रैग एंड ड्रॉप, स्वाइप व्यू, लीनियर और ग्रिड लेआउट, बेहतर वर्चुअलाइजेशन आदि वाले वर्षों के लिए sfListView प्रतिस्थापन की तलाश की। अंत में xamarin CollectionView के साथ बाहर आया और उन्होंने इसे हमारे चेहरे पर लिस्टव्यू के "कूल वर्जन" के रूप में फेंक दिया, लेकिन फिर है यह छोटी गाड़ी है। Uwp के लिए काम नहीं कर रहा है। कई गायब विशेषताएं। बस मुद्दों के भीतर CollectionView की खोज करें, आप उनमें से दर्जनों को समाप्त कर देंगे।

मैं अब भी मानता हूं कि ज़ामरीन क्रॉस प्लेटफॉर्म के लिए सबसे अच्छा उपकरण है और मुझे उम्मीद है कि वे इस मुद्दे को एक रचनात्मक प्रतिक्रिया के रूप में लेंगे।

अब तक की बेहतरीन और रचनात्मक टिप्पणियाँ। मैं सूची पढ़ रहा था, और अन्य देवों के समान ही महसूस कर रहा था। हम में से उन लोगों के बीच समस्याएं आम हैं जो एंटरप्राइज़ ऐप्स विकसित करने के लिए Xamarin.Forms का उपयोग करते हैं। बग ट्रैकिंग और फिक्सिंग पर अधिक ध्यान देने की आवश्यकता है, लेकिन विशेष रूप से, एक बिंदु जो स्पष्ट है, और कई बार मैंने खुद से पूछा है कि Xamarin.Forms के साथ कोई एंटरप्राइज़ MS एप्लिकेशन क्यों नहीं बनाया गया है। एमएस टीम या कोई अन्य। यदि उत्तर है: Xamarin.Forms के साथ जटिल या असंभव करने का तरीका, संपूर्ण रूप से प्लेटफ़ॉर्म को बेहतर बनाने और उन मुद्दों को ठीक करने का प्रयास करने के लिए एक महान आंतरिक अंतर्दृष्टि है। Xamarin/MAUI निश्चित रूप से अधिक डेवलपर्स परीक्षण, योगदान और शब्द फैलाने के साथ लाभ प्राप्त करेगा, लेकिन यह दो-तरफा सड़क होनी चाहिए। फिर से, मैं शिकायत नहीं कर रहा हूं, लेकिन यह देखना बहुत बड़ा होगा, इस साल, अगले साल, MAUI या Xamarin के साथ निर्मित मोबाइल एप्लिकेशन का एक बेहतरीन MS रिलीज़। डेवलपर्स को उनकी कुंठाओं या संभावित सुधारों के लिए भी जांचें, और क्रॉस प्लेटफॉर्म विकास को एक नए स्तर पर ले जाएं।

क्योंकि, मेरा उल्लेख किया गया था ...

मैं एंड्रॉइड और विंडोज डेस्कटॉप (डब्ल्यूपीएफ) के बीच एक क्रॉस प्लेटफॉर्म एप्लिकेशन के लिए एक छोटी परियोजना का नेतृत्व करता हूं।

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

आधिकारिक पाइपलाइन में बग लाना हमारी छोटी टीम के लिए वास्तव में महंगा है , इसलिए अधिक ध्यान आकर्षित करना अच्छा होगा, हो सकता है कि आप समुदाय से अधिक प्राप्त करें।

xamarin के wpf भाग में करने के लिए बहुत कुछ है। प्रदर्शन खराब है और यह साधारण बगों का नरक है। लेकिन इसके पीछे का विचार और आधार निर्धारित है। यह दुखद है कि वर्तमान स्थिति को देखें, क्योंकि यह और भी बेहतर हो सकता है...

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

मुझे कुछ संबंधित बिंदु दिखाई दे रहे हैं

1. मैं नहीं जानता कि कितने लोग फ़ॉर्म पर काम करते हैं, लेकिन मुझे ऐसा लगता है कि नई बग या पीआर की तेज़ी से बढ़ती गति के साथ टीम बहुत छोटी है। यह केवल बदतर होता जा रहा है क्योंकि उन्हें फॉर्म और माउ के बीच ध्यान बांटना होगा। मुझे वास्तव में उम्मीद है कि टीम को जल्द ही काफी बढ़ावा मिलेगा।
2. यह वास्तव में मदद करेगा यदि Microsoft वास्तव में अपने स्वयं के ऐप्स पर फ़ॉर्म का उपयोग करना शुरू कर दे। और मेरा मतलब साधारण डेमो या कॉन्फ़्रेंस ऐप्स से नहीं है। मेरा मतलब है टीम्स या आउटलुक जैसे असली ऐप। मुझे खुशी होगी अगर मैं इस पर गलत हूं लेकिन मुझे स्टोर पर कोई एमएस फॉर्म ऐप नहीं मिला और इस ट्वीट जैसे कुछ स्रोत के अनुसार https://twitter.com/safaiyeh/status/1219294459298344961 वे ज्यादातर प्रतिक्रिया का उपयोग करते हैं मूल निवासी।

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

1. मुझे इस तथ्य में एक और समस्या दिखाई देती है कि एमएस लगातार पहले से सिद्ध और मौजूदा समाधानों जैसे विन यूआई एक्सएएमएल का उपयोग करने के बजाय एक्सएफ एक्सएएमएल के रूप में पहिया को फिर से शुरू करने का प्रयास करता है। उन्हें पहले से मौजूद सुविधाओं को विकसित करने और उसके कारण पेश किए गए बग को ठीक करने में समय लगाना पड़ता है और फिर अन्य सुविधाओं और बग फिक्स के लिए कम समय होता है।

मैं आपके द्वारा उल्लिखित कई मुद्दों से सहमत हूं। Microsoft को निश्चित रूप से Xamarin Forms या iOS या Android का उपयोग करके एक एंटरप्राइज़ ऐप बनाने की आवश्यकता है। एक बार जब उनके पास एक कामकाजी उद्यम ऐप उदाहरण होता है, तो हम शिकायत नहीं कर सकते कि पेशेवर ऐप बनाना निराशाजनक है।

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

Xamarin Hot Reload जैसी सुविधाएँ अभी भी अपने विकास के चरण में समय से पहले हैं। उदाहरण के लिए, यदि मैं App.xaml या App.xaml से संदर्भित संसाधन शब्दकोश में शैली परिवर्तन करता हूं, जहां मैं अपनी शैलियों और संसाधनों को संग्रहीत करता हूं, तो Hot Reload सिम्युलेटर में ऐप के लेआउट को गड़बड़ कर देगा या इसका कारण होगा क्रैश करने के लिए ऐप।

मुझे लगता है कि Xamarin ऐप्स विकसित करते समय विजुअल स्टूडियो अविश्वसनीय रूप से छोटी है। उदाहरण के लिए, यदि मेरे एंड्रॉइड प्रोजेक्ट को स्टार्टअप प्रोजेक्ट के रूप में चुना गया है, तो इसके साथ परीक्षण करें, और फिर मेरे आईओएस प्रोजेक्ट पर मेरे स्टार्टअप प्रोजेक्ट के रूप में स्विच करें, यह सभी प्रकार की झूठी त्रुटियों को दिखाएगा। बिन या ओबीजे फ़ोल्डरों को नष्ट करने से मदद नहीं मिलती है। मुझे वीएस को पुनरारंभ करने की आवश्यकता है। एक अन्य उदाहरण में, जब मैं अपने ऐप को डिबग कर रहा हूं, तो वीएस यादृच्छिक रूप से मेरे मैक से अपना कनेक्शन खो देगा। इससे मेरा वीएस जम जाएगा। मैं एक गुस्से का आवेश फेंक दूंगा, एक मोबाइल डेवलपर के रूप में अपने शौक और अपने जीवन पर सवाल उठाऊंगा, और टास्क मैनेजर का उपयोग करके वीएस को मारने के लिए मजबूर करूंगा। इसके अलावा, मुझे लगता है कि विजुअल स्टूडियो के भविष्य के संस्करण उन बगों को फिर से प्रस्तुत करते हैं जो पूर्व संस्करणों में तय किए गए थे। नवीनतम संस्करण जारी होने के बाद मुझे वीएस के पूर्व संस्करण को स्थापित करने के तरीके के बारे में कोई तरीका नहीं पता है और मैं इसे स्थापित करता हूं। मैं इसे अनइंस्टॉल कर सकता हूं और इंस्टॉलर का उपयोग करके पुनः इंस्टॉल करने का प्रयास कर सकता हूं, लेकिन यह हमेशा नवीनतम संस्करण स्थापित करेगा। यह एक NuGet पैकेज की तरह नहीं है जहां आप किसी भी संस्करण को स्थापित कर सकते हैं।

अंत में, खंडित टैब नियंत्रण पहले से ही Xamarin टूलकिट का हिस्सा क्यों नहीं है? खंडित टैब लगभग हर जगह उपयोग किए जाते हैं। मुझे ऐसे नियंत्रण का उपयोग करने के लिए सिंकफ्यूजन टूलकिट या किसी अन्य टूलकिट का उपयोग नहीं करना चाहिए जो इतना सामान्य है।

मैं MAUI का उपयोग करने से घबरा रहा हूं जब यह किसी भी पेशेवर ऐप में आता है जिसे मैं तब तक विकसित करता हूं जब तक कि Xamarin और Visual Studio का उपयोग करके इनमें से कई डेवलपर निराशाओं का समाधान नहीं हो जाता। जब यह सामने आएगा तो मैं इसके साथ खेलूंगा और प्रयोग करूंगा। लेकिन मुझे और अधिक आत्मविश्वास मिलेगा यदि माइक्रोसॉफ्ट बाहर आता है और साधारण डेमो ऐप बनाने के बजाय एमएयूआई का उपयोग करके एंटरप्राइज़ ऐप बनाता है।

क्या कोई हमें Xamarin प्रपत्रों और MAUI रोडमैप के बारे में बता सकता है? क्या उन्हें समानांतर में बनाए रखा जाएगा? क्या Xamarin प्रपत्र समर्थन के लिए एक कठिन पड़ाव है और क्या Microsoft भविष्य के Visual Studio अद्यतन में MAUI को हमारे गले से नीचे उतार देगा?

शुक्रिया

@SunnyMukherjee अक्सर पूछे जाने वाले प्रश्नों से,

Xamarin.forms का भविष्य क्या है?

Xamarin.Forms का अगला प्रमुख संस्करण सितंबर 2020 के आसपास होगा और .NET 6 के साथ .NET MAUI के रिलीज के माध्यम से अपडेट किया जाना जारी रहेगा। उसके बाद, Xamarin.Forms को 12 महीनों के लिए प्राथमिकता सर्विसिंग प्राप्त होती रहेगी।

मूल रूप से, Xamarin.Forms संस्करण 5 के बाद मारे जाएंगे।

@SunnyMukherjee अक्सर पूछे जाने वाले प्रश्नों से,

Xamarin.forms का भविष्य क्या है?

Xamarin.Forms का अगला प्रमुख संस्करण सितंबर 2020 के आसपास होगा और .NET 6 के साथ .NET MAUI के रिलीज के माध्यम से अपडेट किया जाना जारी रहेगा। उसके बाद, Xamarin.Forms को 12 महीनों के लिए प्राथमिकता सर्विसिंग प्राप्त होती रहेगी।

मूल रूप से, Xamarin.Forms संस्करण 5 के बाद मारे जाएंगे।

2021 के मध्य तक। . . अगर कोविद ने मुझे पहले नहीं मारा, तो माउ या ज़ामरीन फॉर्म काम करेंगे।

@SunnyMukherjee मैंने आपका दर्द सुना। मैं Xamarin.Forms का उपयोग कर रहा हूं क्योंकि यह पहली बार बाहर आया था, और यह वहां से साथ आया है। याद रखें कि Microsoft ने Xamarin.Forms नहीं बनाए थे, उन्होंने केवल 2018 में Xamarin को खरीदा था। इसलिए MAUI Microsoft का प्रोजेक्ट है कि इसे बेहतर बनाने के लिए इसे फिर से लिखें और इसे संपूर्ण .net के साथ निर्बाध रूप से काम करें। Xamarin.Forms के साथ काम करना तुच्छ नहीं है क्योंकि इसे जो करना है वह तुच्छ नहीं है। बहुत से लोग कह रहे हैं कि उन्हें वही करना चाहिए जो ऊनो या स्पंदन ने किया है और नियंत्रण पूरी तरह से स्वयं करना चाहिए - लेकिन यह Xamarin.Forms के खिलाफ है। यह एक मूल विकास ढांचा है - मूल नियंत्रण को सामान्य तरीके से उजागर करना। यह कोई छोटा काम नहीं है। मेरे पास Xamarin.Forms के साथ भी बहुत सारी समस्याएं हैं, लेकिन पूरे समय एक ही ऐप को कई भाषाओं में लिखने के बजाय इसका उपयोग करने से बचाई गई परेशानी से कहीं अधिक है। साथ ही बैकएंड ASP.Net कोर प्रोजेक्ट्स के साथ 90% कोड साझा करने में सक्षम होने से यह और भी अधिक सार्थक हो जाता है।
हालांकि Microsoft को यह बताना महत्वपूर्ण है कि हम MAUI में क्या चाहते हैं - लेकिन हमें यह समझना होगा कि यह उनके लिए कोई छोटा काम नहीं है, और मुझे आशा है कि MAUI सही दिशा में एक बड़ा कदम होगा।
डेमो के MAUI के हालिया बिल्ड के इस वीडियो को देखें और समझाएं कि यह रोडमैप में कैसे फिट बैठता है और यह भी कि वे क्या करेंगे और इस बीच Xamarin.Forms पर समर्थन करेंगे:
https://channel9.msdn.com/Events/Build/2020/BOD106?ocid=AID3012654&WT.mc_id=Build2020_pmmsocialblog

यहाँ पढ़कर मैं सोच रहा हूँ कि Xamarin.Forms की गुणवत्ता में सुधार करने के लिए मैं यहाँ क्या सीख सकता हूँ। मुझे @Happypig375 के मूल प्रश्न पर

कैसे सुधार किया जाए इस पर कोई विचार?

अभी और शिपिंग के बीच हमारे मुख्य लक्ष्यों में से एक .NET MAUI नींव में सुधार कर रहा है, प्रारंभिक बिंदु। इस कारण से हम CollectionView मुद्दों पर अपने वर्तमान स्प्रिंट का अधिक खर्च कर रहे हैं, और हम Xamarin.Forms 5 में फीचर डेवलपर को रोकने का प्रस्ताव कर रहे हैं, इसलिए हमारे पास समस्या समाधान पर अधिक ध्यान केंद्रित करने के लिए सितंबर 2020 से नवंबर 2021 तक का समय है।

यह सब हमारे स्प्रिंट प्रोजेक्ट बोर्ड पर दिखाई देता है।

संक्षेप में:

• समुदाय पुल अनुरोध पर अधिक तेज बनें।

मैंने कुछ दिन पहले पुल अनुरोध पेड़ को दोबारा लगाया था। समीक्षा में इतना समय क्यों लग रहा है?

डब्ल्यूपीएफ-रेंडरर, संभावित बग के बिंदु:

• नियंत्रणों को मापें/व्यवस्थित करें
• लॉजिकल/विजुअल-चाइल्डट्री टूटा हुआ है
• प्रदर्शन

हाय @davidortinau , मुझे लगता है कि इससे निपटने का एक अच्छा तरीका सार्वजनिक रूप से किसी को इसमें शामिल होने के लिए समर्पित करना है:

• बग मुद्दा ट्राइएज
• पीआर समीक्षा और विलय के लिए प्रबंधन, प्रेषण और धक्का।

अगर कुछ बहुत धीमा हो जाता है तो वह हमारे संपर्क का बिंदु होगा और वह समझा सकता है कि क्या हो रहा है।
इसके अलावा, अगर गैर कानूनी बाधाएं हैं, तो यह शानदार होगा यदि हमारे पास एक ट्विच चैनल हो जहां बदले में कोई बग ठीक करे या पीआर ऑनलाइन समीक्षा करे। IHMO, बाहरी डेवलपर्स के हित और सहयोग पर इसका जबरदस्त प्रभाव हो सकता है।
यह दोनों .NET MAUI और Xamarin प्रपत्रों के लिए मान्य है। लेकिन शायद मैं सिर्फ एक सपने देखने वाला हूँ

मैं वास्तव में आश्चर्यचकित नहीं हूं कि Xamarin.Forms में चल रहे प्लेटफ़ॉर्म की संख्या और प्लेटफ़ॉर्म से परिवर्तन या अपने स्वयं के विकास पर विचार करते हुए बहुत सारी बग हैं।

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

अधिक परीक्षण कुछ ऐसा है जिसे मैं एमएयूआई के लिए Xamarin.Forms से लिए गए पाठ के रूप में देखना चाहता हूं। यह रिपोर्ट किए गए और बर्बाद संसाधनों के बहुत सारे मुद्दों से बच सकता है क्योंकि बग्गी कोड ने बनाए गए पीआर के साथ तुरंत संबोधित किए जाने के बजाय लंबा रास्ता तय किया।

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

ढांचे में सुधार करने के लिए। मैं जोड़ना चाहूंगा:

अपना खुद का रेंडरर लिखने की संभावना में सुधार करें। कीवर्ड internal बचें।

GitHub पर केवल नमूना प्रोजेक्ट पोस्ट करने के बजाय, Microsoft OneDrive या Xbox ऐप जैसे Xamarin Forms, iOS या Android के साथ एक पेशेवर, एंटरप्राइज़ ऐप बना सकता है और इसे ऐप स्टोर पर प्रकाशित कर सकता है ताकि डेवलपर्स के अलावा अन्य लोग इसका उपयोग कर सकें। माइक्रोसॉफ्ट ने विजुअल स्टूडियो को सी ++ से सी # और डब्ल्यूपीएफ में माइग्रेट करके पहले किया है (दी गई है कि ग्राहक उस मामले में डेवलपर है)। यह Microsoft को हमारे दर्द बिंदुओं के बारे में बताएगा और यदि वे सफल होते हैं, तो यह डेवलपर समुदाय को जबरदस्त विश्वास दिलाएगा कि Xamarin के साथ कुछ भी संभव है।

मुझे खुशी है कि इस पर एक पोस्टिंग है और मैं अपनी निराशा में वजन करना चाहता हूं। मैं अक्सर मौजूदा मुद्दे के उत्तर पोस्ट करने में निष्क्रिय रहता हूं, लेकिन जो मुझे ट्रिगर करता है वह है BundleAssemblies के संबंध में यह मुद्दा ; इस उच्च प्रभाव वाले मुद्दे के 2 महीने से अधिक समय के बाद, मुझे अभी भी इस बात का कोई स्पष्ट संकेत नहीं है कि Xamarin सदस्यों से समाधान, स्थिति या पथ क्या है।

मैं Agile Scrum टीम चलाता हूं, और अक्सर KPI वेलोसिटी (किए गए काम की मात्रा) है। कभी-कभी, जब हमारे मुद्दे एक निश्चित गर्म स्तर तक बढ़ जाते हैं, तो मेरा अंतिम कथन हमेशा होगा "... मैं सोच रहा हूं कि" [हमारे उत्पाद] की गुणवत्ता में सुधार करने के लिए मैं यहां क्या सीख सकता हूं। कोई अपराध नहीं (वास्तव में), लेकिन यह सिर्फ मेरे मालिक या हमारे ग्राहक को संरक्षण देना है। जब मैं कहता हूं कि उस तरह की चर्चा के संदर्भ में, इसका मतलब केवल यह होगा कि मैं या मेरा उत्पाद स्वामी काम पर नहीं है या हम इनकार की स्थिति में हैं या सबसे खराब स्थिति में हैं, हम वास्तव में नहीं जानते कि क्या हो रहा है। (धन्यवाद हमारे एक हितधारक को, जिसने मुझ पर तमाचा जड़ दिया)

वास्तव में मुझे जो परेशान करता है वह है रिग्रेशन बग और इस मुद्दे पर किसी संक्षिप्त प्रतिक्रिया/स्पष्टीकरण की कमी। हर एक XF रिलीज़ में कुछ न कुछ टूटने का खतरा होता है; और यह कुछ ऐसा तोड़ता है जो स्पष्ट है - संरेखण गलत है, छवि दिखाई नहीं दे रही है, पाठ काट-छाँट काम नहीं कर रहा है और आदि। हमारे आधे परीक्षण मामले केवल इन एक्सएफ प्रतिगमनों की जांच करने के लिए हैं; यह हास्यास्पद है। जाहिर है कि एक्सएफ आंतरिक परीक्षण में कुछ गड़बड़ है। यहां तक ​​​​कि जब एक शो-स्टॉपर बग को स्वीकार किया जाता है, तब भी कई नई रिलीज़ हो सकती हैं; जब हम इसका उपयोग नहीं कर सकते हैं तो उन नई रिलीज़ का क्या मतलब है? क्या उन नई रिलीज़ को आपके बीटा में नहीं जाना चाहिए?

यह सब कहने के बाद, मैं और हमारे हितधारक एक्सएफ के साथ "विषाक्त संस्कृति" के बारे में बहुत थके हुए हैं। यह इस तरह है कि विंडोज 10 कैसे अपडेट जारी कर सकता है जो उपयोगकर्ता की फाइलों या ईंट उपयोगकर्ता के सिस्टम को हटा देता है (लेकिन कम से कम उनकी प्रतिक्रिया और हॉटफिक्स त्वरित है)। मेरा मानना ​​है कि यहां हमारी निराशा एक्सएफ में सुविधाओं की कमी के बारे में नहीं है, बल्कि यह रिलीज की गुणवत्ता के बारे में है। XF कैसे गुणवत्ता में सुधार कर सकता है? आप ऑनलाइन खोज कर सकते हैं और लाखों परिणाम प्राप्त कर सकते हैं; और मैं यह भी सुनिश्चित नहीं कर पा रहा हूँ कि Microsoft की "गुणवत्ता आश्वासन" की समझ को कम करने के लिए अभिमानी हुए बिना यहाँ कहाँ से शुरू करूँ। मुझे यकीन है कि Microsoft जानता है कि गुणवत्ता आश्वासन कैसे करना है (अरे, मैंने इस पर Microsoft के श्वेत-पत्र पढ़े)। यह प्रभारी व्यक्ति के लिए उबलता है; उसे गुणवत्ता जांच में सुधार (या कार्यान्वित) करने के लिए जिम्मेदारी, जवाबदेही और प्रतिबद्धता की आवश्यकता है।

मुझे लगता है कि एक्सएफ के बारे में सबसे निराशाजनक बात यह है कि जब हमारे योगदान (चाहे वह एक नया पीआर, एक नया मुद्दा, या यहां तक ​​​​कि एक साधारण प्रश्न या प्रतिक्रिया हो) को टीम द्वारा अनदेखा कर दिया जाता है।
टीम शायद बहुत छोटी है। लेकिन एक व्यक्ति को उचित समय के भीतर जवाब देने के लिए समर्पित होने से निश्चित रूप से मदद मिलेगी।

BundleAssemblies के संबंध में यह प्रतिगमन एक अच्छा उदाहरण है (इसका पहले ही कई बार उल्लेख किया जा चुका है)।
संग्रह दृश्य के संबंध में यह

मेरे लिए एक और चिंता यह है कि एक एक्सएफ ऐप निश्चित रूप से एक्सएफ में बदलाव से प्रभावित होता है, लेकिन मोनो, विजुअल स्टूडियो, एक्समरिन फ्रेमवर्क, डॉटनेट और यहां तक ​​​​कि कुछ माइक्रोसॉफ्ट लाइब्रेरी भी।
मुझे लगता है कि वे टीमें आंतरिक रूप से अच्छी तरह से संवाद नहीं करती हैं।
मेरी राय में, Microsoft द्वारा अपने ऐप्स के लिए आंतरिक रूप से XF का उपयोग करने से निश्चित रूप से मदद मिलेगी।

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

यहाँ के लोगों ने बहुत अच्छा काम किया है जो मैं विस्तार से कहने वाला था, इसलिए मैं इसे जल्दी करने वाला हूँ

तकनीकी समस्याएँ

• एक्सएफ के साथ काम करते समय विजुअल स्टूडियो 3 गुना/मिनट से अधिक दुर्घटनाग्रस्त हो जाता है।
• बहुत सारे बुनियादी नियंत्रण गायब हैं, या उन्हें आकार देने के लिए एक बिल्ली की आवश्यकता है जैसा कि उन्हें होना चाहिए था।
• जब आप एक्सएफ कहते हैं तो आप सबसे खराब प्रदर्शन क्रॉस प्लेटफॉर्म फ्रेमवर्क कह रहे हैं, और मुझे उन लोगों के लिए स्पष्ट होना चाहिए जो एक्सएफ देशी एंड्रॉइड/आईओएस से निपटते हैं ... और वह कठिन है। सिर्फ देखो! कृपया देखें! ईश्वर प्रेम के लिए! स्पंदन, RN, नेटिवस्क्रिप्ट पर... उन सभी का लक्ष्य एक ही है लेकिन XF बहुत पीछे है
• हॉट रीलोड तभी अच्छा काम करता है जब आप एक नया प्रोजेक्ट बनाते हैं और बाईं ओर डिफ़ॉल्ट टेक्स्ट बनाते हैं और वह है, फिर आप अपने दम पर!
• हर रिलीज में उदाहरण के लिए स्पंदन समुदाय में हर कोई ऐसा होना चाहिए: ओह ओएमजी यह बहुत अच्छा है कि उन्होंने क्या किया, दूसरी तरफ एक्सएफ कॉम जैसा हो: देखते हैं कि उन्होंने क्या तोड़ दिया या उन्होंने क्या जोड़ा कि कॉम को केवल 10% की जरूरत है!
• एक्सएफ का उपयोग करके एक प्रारंभिक यात्रा हेक की एक श्रृंखला है, एक उदाहरण होगा: हाल ही में मुझे Playstore पर सभी ऐप्स में सामान्य नियंत्रणों में से एक बनाना था जो केवल एक साधारण निचला टैब आइकन है, केवल आइकन के साथ खोल का उपयोग करना एक बड़ा मार्जिन है नीचे जो बदसूरत दिखता है और हर किसी की तरह, मैंने एक मुद्दा बनाया, केवल यह ध्यान देने के लिए कि इसी तरह के मुद्दे को 6 महीने पहले और अधिक संबोधित किया गया था ... और रास्ते में कोई फिक्स नहीं
• एक ऐप के बारे में सोचो ठीक है? कोई ऐप? क्या इसमें ऐप खरीदारी या किसी प्रकार की प्रीमियम सेवा है? बिलकुल यह करता है। तो आप गूगल पे और एप्पल पे के लिए प्लगइन की तलाश शुरू कर दें, है ना? या पेपैल भी सही? मैं आपको कुछ बताता हूँ, वहाँ नहीं है !!! जब आप एक्सएफ की आधिकारिक टीम से पूछते हैं, तो आप जानते हैं कि वे क्या जवाब देंगे? वे आपको 2 साल पहले बिना किसी अपडेट के एक आदमी (जिसका मैं सम्मान करता हूं) द्वारा बनाए गए पुराने नहीं आधिकारिक प्लगइन का लिंक भेजते हैं, डब्ल्यूटीएफ (क्षमा करें) !!

तकनीकी नहीं

• ओह आओ, यहां तक ​​​​कि आधिकारिक दस्तावेज भी बहुत खराब है, वे एक टूडू ऐप स्तर की सुविधाओं और कैसे-कैसे ट्यूटोरियल से निपटते हैं
• XF को इस्तेमाल करने से पहले ही मुझे उससे नफरत थी, जानिए क्यों? हर कोई कहता है कि एमएस भी इसका इस्तेमाल नहीं करता है तो आप एफ का इस्तेमाल क्यों करेंगे?
• मुद्दों और पीआर के लिए एक बहुत धीमी प्रतिक्रिया जो समुदाय अपने समय और स्वयं के खर्च पर एक्सएफ टीम की मदद करने के लिए करता है !!!

समाधान

• एक्सएफ टीम बहुत छोटी है, माइक्रोसॉफ्ट जैसी बड़ी कंपनी कैसे अपने उत्पाद को बेहतर बनाने के लिए पर्याप्त लोगों को काम पर नहीं रखती है? दुनिया भर में हर जगह ऐसी प्रतिभाएँ हैं जो Microsoft से उतना ही प्यार करती हैं जितना मैं करता हूँ!
• एक्सएफ को रिलीज करने से पहले उच्च स्तरीय मुद्दों से निपटना चाहिए, यह केवल दिखाता है कि टीम कितनी अपरिपक्व है, जैसे जहाज जो परवाह करता है ...
• Microsoft सबसे अधिक है और अपने उत्पादों के लिए XF का उपयोग करने के लिए बाध्य है! अगर यह सिर्फ यह कहने का एक तरीका नहीं है कि एक्सएफ अच्छा है, लेकिन नहीं, मुझे यह पसंद नहीं है
• एक बहुत समृद्ध दस्तावेज बनाओ! एक डॉक्टर जो ज्यादातर स्थितियों में सबसे पहले जाता है, अधिक लोगों को नियुक्त करता है! यह उतना ही आसान है, बहुत सारे अनुभवी देव हैं जो ब्लॉग करते हैं आप उनके साथ काम कर सकते हैं
• एक्सएफ को स्पंदन के रूप में ज्यादा नहीं जाना जाता है, यूट्यूब पर बड़े कोडिंग प्रभावकों के साथ साझेदारी करें, यहां तक ​​​​कि एक साधारण उल्लेख भी एक्सएफ की मदद करता है
• इसके ओके भी अन्य उत्पादों को देखें और देखें कि देव उनके बारे में क्या पसंद करते हैं और अपना खुद का संस्करण बनाते हैं। उदाहरण के लिए स्पंदन।
• समुदाय से यह पूछने से न डरें कि वे क्या चाहते हैं, एक चट्टान के नीचे न रहें और वह बनाएं जिसका कोई उपयोग नहीं करेगा!

मुझे अपने आक्रामक व्यवहार और अपनी खराब अंग्रेजी के लिए बहुत खेद है, मुझे वास्तव में एक्सएफ पसंद है!
माउ एक नया शुरुआती बिंदु है कृपया इसे नई क्रांति बनाएं, हर कोई कुछ महान होने की उम्मीद कर रहा है इसलिए कृपया हमें निराश न करें, हमें बड़ी उम्मीदें हैं।

@Amine-Smahi कृपया व्यवहार के बारे में अधिक जानकारी के साथ ईमेल पर पहुंचें जो क्रैश की ओर ले जाता है ([email protected])।

मैं पूरी तरह से सहमत हूं कि बग फिक्सिंग और नई फीचर परीक्षण प्रक्रिया भयानक है।

उदाहरण के लिए:
https://github.com/xamarin/Xamarin.Forms/issues/3335 - ListView.RecycleElement का उपयोग करने से रोकता है
https://github.com/xamarin/Xamarin.Forms/issues/4168 - CompressedLayout का उपयोग करने से रोकता है

जब आप प्रदर्शन में सुधार करने वाली नई सुविधाएँ जोड़ते हैं - यह बहुत अच्छा है! लेकिन जब ये सुविधाएँ अनुपयोगी होती हैं, तो यह बहुत निराशाजनक होता है।

और कुछ समस्याएं जो मेरे ऐप्स को प्रभावित करती हैं और लंबे समय तक ठीक नहीं होती हैं:
https://github.com/xamarin/AndroidX/issues/64
https://github.com/xamarin/Xamarin.Forms/issues/5087
https://github.com/xamarin/Xamarin.Forms/issues/5127
https://github.com/xamarin/Xamarin.Forms/issues/3168
https://github.com/xamarin/Xamarin.Forms/issues/8058 https://github.com/xamarin/Xamarin.Forms/issues/10055
https://github.com/xamarin/xamarin-android/issues/3341
https://github.com/xamarin/xamarin-android/issues/3480

टीम को उनके द्वारा लागू की जाने वाली सुविधाओं की जिम्मेदारी लेनी चाहिए। उदाहरण के लिए, @StephaneDelcroix ने https://github.com/xamarin/Xamarin.Forms/pull/1136 लागू किया https://github.com/xamarin/Xamarin.Forms/issues/4168 के लिए असाइन किया जाना चाहिए और CompressedLayout-संबंधित बग्स को ठीक करना चाहिए।

दस्तावेज़ीकरण के बारे में: मुझे व्यक्तिगत रूप से लगता है कि यह ज्यादातर ठीक है, रिलीज नोट्स को छोड़कर, जो पूरी तरह से f * d up हैं;) (हमेशा देर से या अधूरा)
दोबारा, मैं विशेष रूप से एक्सएफ के बारे में बात नहीं कर रहा हूं, लेकिन आम तौर पर पूरे xamarin ढांचे (xamarin.android, xamarin.ios, विजुअल स्टूडियो, मोनो, घटकों ...) के बारे में बात कर रहा हूं।

यहाँ एक उदाहरण है: xamarin ios रिलीज़ नोट्स

@ मेलिमियन

जब आप प्रदर्शन में सुधार करने वाली नई सुविधाएँ जोड़ते हैं - यह बहुत अच्छा है! लेकिन जब ये सुविधाएँ अनुपयोगी होती हैं, तो यह बहुत निराशाजनक होता है।

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

अब, जब मुझे "हमने जोड़ा" शीर्षक दिखाई देता है, तो मैं तुरंत आगे स्क्रॉल करता हूं।
और आपके पास अन्य तत्व भी हैं, उदाहरण के लिए
Swipeview,Expander, जिसमें बहुत सारी त्रुटियाँ भी हैं।
और फिर वहाँ है, जैसा कि व्यक्ति ने ऊपर लिखा है, मोनो, विजुअल स्टूडियो अपने स्वयं के बग के साथ।

4.7-4.8 में नई सुविधाओं को रद्द करें, बग फिक्स के लिए ध्यान दें।
Xamarin पर विकास समाधान खोजने, अस्थायी समाधान खोजने जैसा है।
मैं अपनी खराब अंग्रेजी के लिए क्षमा चाहता हूँ

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

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

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

@freever मैं पूरी तरह सहमत हूँ!
यह न केवल वर्तमान Xamarin देवों को खुश करेगा, बल्कि यह MAUI के लिए भी उन बगों को हल करेगा!

मुझे नहीं पता कि इन बग्स को यहां MAUI में ठीक करने के लिए किया जाएगा, या क्या उन्हें Xamarin.Forms में ठीक किया जाएगा।

मुझे ऐसा लगता है कि @davidortinau ने यहां इस मुद्दे की भावना को कवर किया है

https://github.com/dotnet/maui/issues/109#issuecomment -635078640

मैंने उनकी टिप्पणी के साथ विवरण अपडेट किया है

मैं वास्तव में इस हिस्से को उजागर करना चाहता हूं जो उसने फिर से सभी के लिए कहा था

हम CollectionView मुद्दों पर अपने वर्तमान स्प्रिंट का अधिक खर्च कर रहे हैं, और हम Xamarin.Forms 5 में फीचर डेवलपर को रोकने का प्रस्ताव कर रहे हैं, इसलिए हमारे पास समस्या समाधान पर अधिक ध्यान केंद्रित करने के लिए सितंबर 2020 से नवंबर 2021 तक का समय है।

PureWeen ने इसे 10 घंटे पहले बंद कर दिया था

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

@PureWeen इस मुद्दे में केवल बग की संख्या से कहीं अधिक शामिल है। वे बिंदु रूप में भी सूचीबद्ध हैं।

@tranb3r

मुझे लगता है कि एक्सएफ के बारे में सबसे निराशाजनक बात यह है कि जब हमारे योगदान (चाहे वह एक नया पीआर, एक नया मुद्दा, या यहां तक ​​​​कि एक साधारण प्रश्न या प्रतिक्रिया हो) को टीम द्वारा अनदेखा कर दिया जाता है।

@davidortinau की टिप्पणी आपके लिए कैसे कम है? मैं जो मुख्य बिंदु बना रहा हूं वह यह है कि हम नई सुविधाओं पर विकास को धीमा कर रहे हैं ताकि हम खुले पीआर और बग पर अधिक ध्यान केंद्रित कर सकें और अंततः .net माउ पर पहुंच सकें जो हमारा नया .net 6 आधारित उत्पाद होगा।

@ हैप्पीपिग३७५

@pauldipietro उस व्यक्ति से संपर्क किया जिसने उस मुद्दे को पोस्ट किया ताकि वह उन मुद्दों को सीधे उनके साथ संबोधित करना शुरू कर सके।

इस मुद्दे की भावना यह है कि XF में बहुत अधिक बग हैं और समुदाय की उपेक्षा करता है। इसलिए, हम मौजूदा बग पर अधिक ध्यान केंद्रित करने और पीआर खोलने के लिए नए विकास को धीमा कर रहे हैं

यदि खुले बग के बाहर अन्य मुद्दे हैं तो आइए उनके लिए मुद्दे खोलें। लेकिन यह मुद्दा उनके बहुत अधिक खुले बग होने के बारे में है और हमारे पास इसका समाधान करने की योजना है।

MAUI के साथ, हमारे पास एक बग फिक्सिंग प्रक्रिया होनी चाहिए जो जितनी जल्दी हो सके। कैसे सुधार किया जाए इस पर कोई विचार?

हम .NET माउ के साथ फ़ॉर्म से विरासत के पहलुओं का एक गुच्छा निकाल रहे हैं और हम इस साल खर्च कर रहे हैं इससे पहले कि हम बग और खुले पीआर पर बहुत अधिक ध्यान केंद्रित कर रहे हैं ताकि हम .NET माउ के साथ अधिक उत्पादक बन सकें।

यह हमारा प्रोजेक्ट बोर्ड है

https://github.com/xamarin/Xamarin.Forms/projects

आप देख सकते हैं कि हम प्रत्येक स्प्रिंट में क्या जोड़ रहे हैं
https://github.com/xamarin/Xamarin.Forms/projects/70

ये रहा हमारा रोडमैप
https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap
हम जिस पर काम कर रहे हैं, उसमें यथासंभव पारदर्शी होने का प्रयास करते हैं

यदि उन रेपो पर मुद्दों को पिंग किया जाता है या उच्च फोकस होता है तो हम उन्हें शीर्ष पर लाने की कोशिश करते हैं लेकिन कभी-कभी वे एल्गोरिदम सही नहीं होते हैं।

@ अमीन-स्माही यहाँ शेल के लिए प्रोजेक्ट बोर्ड है और जिसे हम ब्लॉकर्स के रूप में देखते हैं
https://github.com/xamarin/Xamarin.Forms/projects/54

क्या आप मुझे उस मुद्दे पर इंगित कर सकते हैं जिसका आप उल्लेख कर रहे हैं ताकि मैं इसे देख सकूं?

@PureWeen

@davidortinau की टिप्पणी आपके लिए कैसे कम है? मैं जो मुख्य बिंदु बना रहा हूं वह यह है कि हम नई सुविधाओं पर विकास को धीमा कर रहे हैं ताकि हम खुले पीआर और बग पर अधिक ध्यान केंद्रित कर सकें और अंततः .net माउ पर पहुंच सकें जो हमारा नया .net 6 आधारित उत्पाद होगा।

जैसा कि पहले उल्लेख किया गया है, यह समस्या केवल XF में बग की संख्या से कहीं अधिक शामिल है।

यदि खुले बग के बाहर अन्य मुद्दे हैं तो आइए उनके लिए मुद्दे खोलें। लेकिन यह मुद्दा उनके बहुत अधिक खुले बग होने के बारे में है और हमारे पास इसका समाधान करने की योजना है।

पहले से ही बहुत सारे खुले मुद्दे हैं !!! यदि आप उन्हें अनदेखा कर दें तो नए खोलने का क्या मतलब है...

उदाहरण के लिए, पहले उल्लेखित महत्वपूर्ण बिंदुओं में से एक यह है कि Microsoft टीमों को ऐप्स विकसित करते समय xamarin का उपयोग करना चाहिए।
क्या आप यह प्रतिक्रिया सुनते हैं? हमें आपको यह विश्वास दिलाने के लिए क्या करना चाहिए कि यह एक अच्छा विचार है ? क्या हमें इसके लिए कोई मुद्दा खोलना चाहिए ???

जैसा कि पहले उल्लेख किया गया है, यह समस्या केवल XF में बग की संख्या से कहीं अधिक शामिल है।

आइए उनके लिए अलग-अलग मुद्दे बनाएं। एक मुद्दे में कई चीजों को संबोधित करना उत्पादक नहीं होगा।

यहां अन्य कौन सी टिप्पणियां हैं जिनका एक्सएफ के आसपास खुले बग/पीआरएस/नाजुकता चिंताओं से कोई लेना देना नहीं है, क्या आप स्पष्टता चाहते हैं?

उदाहरण के लिए, पहले उल्लेखित महत्वपूर्ण बिंदुओं में से एक यह है कि Microsoft टीमों को ऐप्स विकसित करते समय xamarin का उपयोग करना चाहिए।
क्या आप यह प्रतिक्रिया सुनते हैं? हमें आपको यह विश्वास दिलाने के लिए क्या करना चाहिए कि यह एक अच्छा विचार है ? क्या हमें इसके लिए कोई मुद्दा खोलना चाहिए ???

हां, हम सचमुच सभी को Xamarin का उपयोग करने के लिए मनाने की कोशिश करते हैं

हम ऐप विकल्पों के बारे में आंतरिक टीमों के साथ बहुत सी बातें करते हैं और यह एक सतत चर्चा है। इनमें से बहुत सी आंतरिक चर्चाएं भी .NET माउ की दिशा का मार्गदर्शन करेंगी।

मुझे यकीन नहीं है कि मैं इस बारे में और क्या टिप्पणी कर सकता हूं। विशेष रूप से एक उपयोगकर्ता के रूप में आपकी सहायता करने के लिए मैं यहां बहुत कुछ करने योग्य नहीं हूं।

@PureWeen इस मुद्दे की भावना यह है कि XF में बहुत अधिक बग हैं और समुदाय की उपेक्षा करता है। इसलिए, हम मौजूदा बग पर अधिक ध्यान केंद्रित करने और पीआर खोलने के लिए नए विकास को धीमा कर रहे हैं

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

1. योगदान करना और योगदान की समीक्षा करना आसान बनाने के लिए भंडार को
2. सुविधाओं पर बग फिक्स और क्लीन कोड
3. बग को ठीक करने वाले और कोड को साफ करने वाले परिवर्तनों को तोड़ने की अनुमति दें ।
4. बग्स को कम करने के लिए .Net का
5. पहले सबसे बुनियादी नियंत्रणों को ठीक करें , फिर शेष नियंत्रणों को।
6. जेटीसन पुराने लक्ष्य OSes और पुराने संपादकों को रेपो को साफ करने, परीक्षण को कारगर बनाने और बग फिक्स के लिए संसाधनों को मुक्त करने के लिए।
7. बग्स के मीट्रिक पर सार्वजनिक रूप से रिपोर्ट करें। इससे संगठन को बग पर ध्यान केंद्रित करने में मदद मिलेगी। अद्यतन के बारे में किसी भी ब्लॉग में बग पर प्रगति को पहले खंड के रूप में रखें।
8. रिपोजिटरी के आकार को कम करने के लिए सुविधाओं को

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

योगदान करना और योगदान की समीक्षा करना आसान बनाने के लिए भंडार को सरल बनाएं। नया रेंडरर आर्किटेक्चर मदद कर सकता है यदि यह XAML को कोर से विस्थापित करता है और रेंडरर्स को अधिक टाइप-सुरक्षित दृष्टिकोण देता है।

यही हमारी योजना है। मैंने यहां एक प्लेस होल्डर इश्यू बनाया है जिसका आप अनुसरण कर सकते हैं या अपने सुझाव दे सकते हैं https://github.com/dotnet/maui/issues/147

सुविधाओं पर बग फिक्स और क्लीन कोड को प्राथमिकता दें। यह देखते हुए कि ज़ामरीन की संस्कृति बग को अनदेखा करते हुए नई सुविधाओं को जोड़ना है, सबसे अच्छा तरीका यह है कि मौजूदा सुविधाओं के लिए गुणवत्ता की सीमा पूरी होने तक नई सुविधाओं पर पूर्ण प्रतिबंध लगा दिया जाए।

यह ज्यादातर हमारी योजना है।

बग को ठीक करने वाले और कोड को साफ करने वाले परिवर्तनों को तोड़ने की अनुमति दें।
बग्स को कम करने के लिए .Net का पूरा उपयोग करें। जहां भी संभव हो, चीजों को टाइप सिस्टम के अंदर रखें और C# 8 NRTs को अपनाएं।

यह धीरे-धीरे हमारी योजना है। लेकिन हमारे उत्पादों का उपयोग करने वाले उपयोगकर्ताओं के पूर्ण दायरे को समझना महत्वपूर्ण है। उदाहरण के लिए, एक बार जब हमने बनाम2017 को तोड़ दिया तो इस मुद्दे का समर्थन यहां पॉप अप हुआ, जिसे उपयोगकर्ताओं से एक टन टिप्पणियां मिलीं
https://github.com/xamarin/Xamarin.Forms/issues/7602

इसलिए हम सिर्फ छलांग नहीं लगा सकते। मैं 100 प्रतिशत उस छलांग को लेना पसंद करूंगा लेकिन हम लोगों को तोड़ नहीं सकते।

लेकिन हम इस छलांग के लिए तैयार रहने के लिए लगातार कदम उठाते हैं। उदाहरण के लिए यहां पीआर
https://github.com/xamarin/Xamarin.Forms/pull/10937

मुझे सी # 8 और अन्य बीटा सुविधाओं के खिलाफ परीक्षण करने के लिए आंतरिक सीआई प्रक्रिया चलाने की अनुमति देगा ताकि एक बार जब हम छलांग लगा सकें तो यह एक आसान छलांग होगी।

पहले सबसे बुनियादी नियंत्रणों को ठीक करें, फिर शेष नियंत्रणों को।
जेटीसन पुराने लक्ष्य OSes और पुराने संपादकों को रेपो को साफ करने, परीक्षण को कारगर बनाने और बग फिक्स के लिए संसाधनों को मुक्त करने के लिए।

यह हमारी योजना है जैसा कि मैंने ऊपर उल्लेख किया है

बग्स के मीट्रिक पर सार्वजनिक रूप से रिपोर्ट करें। इससे संगठन को बग पर ध्यान केंद्रित करने में मदद मिलेगी। अद्यतन के बारे में किसी भी ब्लॉग में बग पर प्रगति को पहले खंड के रूप में रखें।

इस पर गौर कर रहे हैं। @samhouts हमारे लिए हर स्प्रिंट के लिए इनमें से बहुत सारी रिपोर्ट चलाता है, इसलिए हमारे पास हर चीज पर नजरिया है लेकिन हम इसे समुदाय के लिए बेहतर तरीके से देखेंगे।

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

यह .net MAUI के साथ हमारी योजना है। अपनी .NET MAUI योजना को लॉन्च करने से पहले हमने उन क्षेत्रों की सूची तैयार की जिन्हें हम कम कर सकते हैं ताकि अधिक प्रभावी हो सकें। इसका एक बड़ा हिस्सा रेंडरर का काम होगा।

नमस्ते, उल्लिखित मुद्दों के अलावा, राइट टू लेफ्ट भाषाओं से संबंधित कई बग हैं। ऐसा लगता है कि ये बग ज़ामरीन फॉर्म्स टीम के दृष्टिकोण से कम महत्व के हैं (शायद अंग्रेजी की तुलना में राइट टू लेफ्ट भाषाओं के कम उपयोग के कारण या अन्य लेफ्ट टू के कारण)। राइट लैंग्वेज), लेकिन राइट टू लेफ्ट संस्कृतियों के लिए पूर्ण समर्थन की कमी, हतोत्साहित करने वाली और निराशाजनक है और वास्तव में डेवलपर्स को अंतर्राष्ट्रीय / बहुभाषी / राइट टू लेफ्ट ऐप्स में XF का उपयोग करने से रोकती है।
धन्यवाद।

अगले दो महीने पुराना अंक: https://github.com/xamarin/Xamarin.Forms/issues/11166
बग बनाया गया 22 जून।
पीआर 25 जून को खुला।
बग स्थिति 17 अगस्त: अभी भी विलय नहीं हुआ है। क्यों? ;(

@PawKanarek Xamarin में आपका स्वागत है। आमतौर पर वे टीम द्वारा बनाए गए केवल फिक्स या पीआरएस को मर्ज करते हैं। इसलिए यह Xamarin पर योगदान करने के लिए हतोत्साहित कर रहा है। मुझे लगता है कि उन्होंने टीम की क्षमता को कम कर दिया। केवल 2-3 लोग ही परियोजना पर सक्रिय रूप से काम कर रहे हैं। यदि आपको त्वरित सुधार की आवश्यकता है तो अपने स्वयं के xamarin nuget संकुल का निर्माण करें।

@EmilAlipiev लेकिन इस बार पीआर (1166 के लिए) Xamarin टीम के एक सदस्य द्वारा खोला गया था और अभी भी xD विलय नहीं किया गया है

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

आप देख सकते हैं कि पिछले महीने में, 18 अलग-अलग लोगों द्वारा 40 नए पुल अनुरोध खोले गए हैं । पुल अनुरोधों का पूरी तरह से परीक्षण और समीक्षा की जानी चाहिए, और हमें प्राप्त होने वाली मात्रा के साथ, हमें बिना किसी समाधान के अवरुद्ध मुद्दों और प्रमुख प्रतिगमन को प्राथमिकता देनी होगी।

मुझे पता है कि हम हमेशा पूर्ण नहीं होते हैं, लेकिन हम हर दिन सुधार करने के लिए काम कर रहे हैं। आपके धैर्य और हमारे साथ बने रहने के लिए धन्यवाद। हम इसे एक साथ कर सकते हैं!

@ hamiddd1980 आपको यह जानकर खुशी होगी कि हम पिछले कुछ महीनों में RTL पर काफी काम कर रहे हैं। मुझे आशा है कि इससे आपके अनुभव में सुधार होगा!

@samhouts बस याद रखें कि आप Xamarin के अंतिम उत्पाद नहीं हैं। हमें न केवल धैर्य की आवश्यकता है, बल्कि बहुत सारे मानव संसाधन और धन की भी आवश्यकता है। जीथब में किसी भी खुले और सत्यापित बग को जल्द से जल्द ठीक किया जाना चाहिए क्योंकि यह हमारे ग्राहकों के साथ तकनीकी ऋण, क्रोध और अनावश्यक तनाव के रूप में एक स्नोबॉल प्रभाव पैदा करता है।

कृपया और बग ठीक करें, अधिक सुविधाएं न जोड़ें। कार्यक्षमता पर स्थिरता। तुम अब भी 1,590 सत्यापित बग हो https://github.com/xamarin/Xamarin.Forms/issues?q=is%3Aopen+is%3Aissue+-label%3As%2Funverified+label%3A%22t%2Fbug+%3Abug%3A% 22

@samhouts आपके उत्तर के लिए धन्यवाद। 1-2 मर्ज प्रति दिन बेहद कम है। मैं अन्य क्रॉस प्लेटफॉर्म टूल पर काम करता हूं और उनके पास पिछले महीने 15 मर्ज प्रति दिन 455 मर्ज हैं। मैं अभी भी Xamarin को उपकरण के रूप में अधिक पसंद करता हूं और मैं हमेशा योगदान करने के लिए तैयार हूं लेकिन मेरे विलय में 2 महीने से अधिक समय लगा और मुझे अलग-अलग शाखा से छूट के साथ इस विलय को 3 बार बनाना पड़ा।
इसके अलावा आपके पक्ष में प्राथमिकता का मुद्दा है। लोग मूल उपकरण जैसे कि Device.Idiom.. या CollectionView बग ​​आदि जैसे बग को ठीक करने के लिए बेताब हैं।
आज वास्तव में अब तक कुल 8 विलय में बहुत प्रगति हुई है। लेकिन मर्ज के नीचे ईमानदार होने के लिए, कम लोग स्वाइप व्यू, ग्रेडिएंट ब्रश या थीम आदि में रुचि रखते हैं, जब ऐसे महत्वपूर्ण पीआर महीनों तक कतार में होते हैं। मेरा मानना ​​है कि यह सबसे बड़ी निराशा है

जीथब में किसी भी खुले और सत्यापित बग को जल्द से जल्द ठीक किया जाना चाहिए

यह स्पष्ट रूप से अवास्तविक है; भले ही Microsoft ने Xamarin.Forms टीम के आकार में नाटकीय रूप से वृद्धि की हो।
वे कहते हैं कि होशियारी से काम करें, कठिन नहीं, वे कहते हैं (इस मामले में, इसका मतलब यह होना चाहिए कि पीआर को प्रतिगमन परीक्षण शामिल करने की आवश्यकता है ताकि यह सुनिश्चित हो सके कि बग फिर से प्रकट न हों; हालांकि, किसी भी चीज़ के साथ, यह भी एक व्यापार-बंद है, क्योंकि योगदान की समीक्षा पीआर लंबे और कठिन हो जाएंगे)।

कृपया और बग ठीक करें, अधिक सुविधाएं न जोड़ें

यह एक राय है जिसे मैं भी साझा करता हूं। हालांकि, कड़ाई से बोलते हुए, MAUI<>Xamarin.Forms संक्रमण योजना में पहले से ही इसे शामिल किया गया है: Xamarin.Forms केवल बग-फिक्सिंग मोड में संक्रमण करेंगे, जबकि नई सुविधाएं केवल माउ पर ही उतरेंगी।

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

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

इससे बहुत देरी होती है, और इसका मतलब है कि पीआर को कभी-कभी परीक्षण पास करने में ही दिन लग सकते हैं। यह हम पर है, और यह एक ऐसी समस्या है जिसे हमें हल करने की आवश्यकता है।

सौभाग्य से, हम इस समस्या पर काम कर रहे हैं। हम वास्तव में UI को स्वचालित करने की तुलना में यूनिट परीक्षणों की तरह प्लेटफ़ॉर्म रेंडरर्स के परीक्षण की एक नई विधि विकसित कर रहे हैं, जो कहीं अधिक विश्वसनीय और तेज़ है।

जहां तक ​​​​नई सुविधाओं को जोड़ने बनाम बग फिक्स करने की बात है ... जैसा कि @knocte कहते हैं, संक्रमण योजना को इसे ध्यान में रखकर बनाया गया है। हमारा लक्ष्य .NET MAUI के लिए दुबला, तेज और विश्वसनीय होना है। इसके भाग के रूप में, हम मूल्यांकन कर रहे हैं कि मुख्य परियोजना में वास्तव में कौन सी विशेषताएं हैं और कौन सी विशेषताएं नए सामुदायिक टूलकिट के लिए बेहतर अनुकूल हैं--जिसमें अभी भी माइक्रोसॉफ्ट का समर्थन है, लेकिन समुदाय द्वारा बड़े पैमाने पर समर्थित है।

कृपया जान लें कि जब भी हम कोई बदलाव करते हैं, तो हम हमेशा आपके और आपके ग्राहकों को ध्यान में रखते हैं, और हम आपकी प्रतिक्रिया सुन रहे हैं।