7049는 버그 보고 7일 후 PR을 병합해도 롤아웃하는 데 1개월 이상 소요되었습니다.

그리고 풀 리퀘스트를 열면 Xamarin의 담당자가 변경된 파일을 살펴볼 시간을 할애할 때까지 여전히 요청이 림보 상태에 빠질 수 있습니다.

팀이 PR + 릴리스 프로세스와 관련된 병목 현상을 제거할 계획이 있기를 바랍니다.

그리고 풀 리퀘스트를 열면 Xamarin의 담당자가 변경된 파일을 살펴볼 시간을 할애할 때까지 여전히 요청이 림보 상태에 빠질 수 있습니다.

그리고, 높은 가시성 문제에서 언급된 후 Xamarin.Forms 팀의 누군가가 마침내 https://github.com/xamarin/Xamarin.Forms/pull/7728에 응답했습니다

그리고 풀 리퀘스트를 열면 Xamarin의 담당자가 변경된 파일을 살펴볼 시간을 할애할 때까지 여전히 요청이 림보 상태에 빠질 수 있습니다.

그리고 높은 가시성 문제에서 언급된 후 Xamarin.Forms 팀의 누군가가 마침내 xamarin/Xamarin.Forms#7728 에 응답했습니다.

팀에 공감합니다. 많은 문제를 분류/관리/수정하기가 쉽지 않습니다. 즉, 병목 현상을 제거하고 미해결 문제 및 PR을 축소하는 데 중점을 두어야 합니다.

품질은 항상 Xamarin 개발의 모든 측면에서 문제였습니다. 여러 번 구성 요소 간의 비호환성, VS에서 작동하지 않는 빌드 또는 새 버전의 Forms로 업데이트한 후 내 앱이 충돌하기 때문에 좌절감을 느낍니다. 물건이 작동해야 합니다. 일부 컨트롤이나 레이아웃이 단순히 함께 잘 작동하지 않기 때문에 세 번째로 레이아웃을 다시 작성해야 하는 것은 아닙니다.

몇 가지 관련 포인트가 보입니다.

1) 얼마나 많은 사람들이 Forms에서 작업하는지 모르지만 제가 보기에는 팀이 너무 작아서 새로운 버그나 PR의 빠른 성장 속도를 따라잡을 수 없는 것 같습니다. Forms와 Maui 사이에 주의를 분산시켜야 하므로 상황이 더욱 악화될 것입니다. 팀이 곧 상당한 발전을 이루기를 진심으로 바랍니다.

2) Microsoft가 실제로 자체 앱에서 Forms를 사용하기 시작했다면 정말 도움이 될 것입니다. 단순한 데모나 회의 앱을 말하는 것이 아닙니다. Teams 또는 Outlook과 같은 실제 앱을 의미합니다. 내가 이것에 대해 틀렸다면 기쁠 것입니다. 그러나 상점에서 MS Forms 앱을 찾지 못했고 이 트윗과 같은 일부 출처에 따르면 https://twitter.com/safaiyeh/status/1219294459298344961 그들은 주로 반응합니다. 토종의.

• MS가 자체 기술(XF)을 사용하지 않으면 왜 우리가 사용해야 하기 때문에 이것은 좋은 신호를 보내지 못합니다.

• 복잡한 앱에서 내부적으로 Forms를 사용하면 추가 테스트 계층이 될 수 있으며 공개 릴리스에 영향을 미치는 문제의 수를 줄일 수 있습니다. 또한 그들은 Forms로 작업하는 것이 그들이 말하는 것만큼 쉽지 않다는 것을 알 수 있었습니다.

3) MS가 Win UI Xaml과 같이 이미 검증된 기존 솔루션을 사용하는 대신 XF Xaml의 형태로 계속해서 바퀴를 재발명하려고 한다는 사실에 또 다른 문제가 있다고 봅니다. 그들은 이미 존재하는 기능을 개발하고 그로 인해 도입된 버그를 수정하는 데 시간을 투자해야 하며 다른 기능 및 버그 수정을 위한 시간이 줄어듭니다.

@Reveon에 100% 동의합니다.
아, 그리고 Xamarin과 함께 Windows용 VisualStudio를 사용하는 것은 매우 실망스러운 경험입니다.

그들은 계속해서 뛰어난 차단, 버그를 추가합니다... 그게 어떻게 가능한지조차 모르겠습니다(모든 ios 장치 빌드 깨기, 프로비저닝 프로필 깨기, 제스처 인식기 깨기 등... 이러한 버그가 어떻게 프로덕션에 들어갈 수 있고 그런 다음 릴리스 빌드에서 수정하는 데 몇 주 또는 몇 달이 걸리나요? 몰라요....)

저는 그것을 위해 Rider로 전환했고 지금은 어디에서나 Jetbrains 제품을 사용하고 있습니다. :) 적어도 iOS와 Windows에서 정확히 동일한 IDE를 사용할 수 있고 계속해서 생산적으로 작업할 수 있습니다.

MAUI를 사용하면 그러한 것들이 바뀔 것이며 조만간 Microsoft는 심각한 프로젝트에 내부적으로 MAUI를 사용하기 시작할 것이라고 확신합니다.

또 다른 증언:
https://github.com/xamarin/Xamarin.Forms/issues/10482#issuecomment -633730446
@EmilAlipiev :

이 문제에 대해 PR 이 1.5개월 동안 병합되기를 기다리고 있습니다. Ios에 이미 존재하는 문제 가 있고 android는 2019년 7월에 수정되었으며 아무도 uwp를 건드리지 않았습니다. 4월에 수정했고 검토 및 병합을 여러 번 요청했습니다. xamarin 팀이 작동하는 방식은 정말 짜증납니다. 하루에 1~2개의 PR만 검토하는 것을 볼 수 있습니다.
#10316

종종 좌절하기도 하지만 "Xamarin is buggy"는 거친 표현입니다. Flutter를 확인하면 오늘 2000개 이상의 미해결 문제가 5000개 이상의 미해결 문제가 있습니다. 숫자는 그렇게 중요하지 않습니다. Xamarin.forms는 uwp(xbox 포함), wpf, mac, gtk, tizen과 같은 다른 크로스 플랫폼보다 더 많은 것을 제공합니다. 예를 들어 우리 대부분에게 우선 순위가 낮은 Wpf에 대한 많은 미해결 문제가 있습니다.
Xamarin.forms의 핵심은 ios, android 및 uwp여야 하지만 Xamarin 팀은 종종 uwp를 무시합니다.

1. 레이아웃, 목록 보기, 회전 목마, 컬렉션 보기, 이미지, 지도, 레이블, 편집기 등과 같은 핵심 요소가 있어야 합니다. 버그가 없어야 합니다. 새로운 릴리스나 업데이트를 하는 경우에는 눈에 띄는 버그가 없는지 확인해야 합니다. 버그가 있는 경우 최대 1주일 이내에 해결해야 합니다. 그러나 Xamarin 팀은 멋진 기능(커뮤니티의 10%에서 이 멋진 도구가 필요한 사람?)과 이미지 제어 기능이 포함된 멋진 "4.5-4.6"을 출시합니다. 문제 는 3월 초에 보고되었으며 오늘까지 해결되지 않았습니다. 동일한 "네이티브 어셈블리로 번들"이 손상되었습니다. 이러한 중요한 이유로 4.5 및 4.6으로 업그레이드할 수 없습니다. 그들은 새로운 기능을 추가하는 4.7로 계속 발전하고 있습니다. 나와 우리 대부분은 버그가 해결되었는지 여부를 릴리스 노트를 주시하고 있으며 어떤 기능이 추가되었는지는 더 이상 읽지 않습니다.
2. Xamarin 팀은 이것을 이해해야 합니다. 많은 사람들이 Xamarin을 선택하는 가장 큰 이유는 "UWP"입니다. 저는 프리랜서입니다. 나는 고객에게 왜 펄럭이지 않거나 네이티브로 반응하는지 묻습니다. 그는 Xamarin에 UWP가 있기 때문에 말합니다. 나도 UWP를 원한다. 그러나 Uwp는 대부분 Xamarin.forms에서 버그가 있습니다. CollectionView를 도입했는데 정말 훌륭하지만 1년 이후로 그 버그가 해결되지 않았습니다. 수정했는데 아무도 리뷰하지 않습니다. 나는 더 이상 기여하는 것을 낙담했습니다.
3. Hotreload가 전혀 작동하지 않습니다. 나는 트위터에서 hotreaload가 얼마나 대단한지 "kiss kiss"를 읽었습니다. 나에게 문제가 있거나 다른 도구를 사용하고 있다고 생각합니다. 종종 hotreload가 업데이트되지 않기 때문입니다. 나는 여전히 livexaml 등과 같은 타사 도구를 사용하고 있습니다. 심지어 내 자신의 hotreload를 수행하기 위해 간단한 콘솔 응용 프로그램도 만들었습니다. 1일이 소요됩니다. Xamarin보다 훨씬 잘 작동하며 uwp에서도 작동합니다. 어떻게 그들이 그것을 배달하지 않을 수 있습니까? 그들은 livereload가 작동하고 있었다.

4. 가장 중요한 점; @Reveon이 언급한 것. xamarin.forms와 함께 작동하는 실제 엔터프라이즈 애플리케이션이 필요하며 실제 문제를 감지하기 위해 새 릴리스로 업데이트해야 합니다. 그들은 "반성하는 것이 그렇게 어렵지 않다"고 불평합니다. 예, 이 문제가 할 일 앱이 아닌 엔터프라이즈 애플리케이션에서만 발생한다면 매우 어렵습니다. 동일한 UI를 복제하려고 시도해야 합니다. 알아낼 때까지 며칠이 걸릴 수 있습니다. 그렇기 때문에 큰 응용 프로그램을 가진 사람이 있어야 하는 것이 매우 중요합니다. twitch, youtube, twitter 등에서 볼 수 있는 Xamarin 개발자 중 xamarin.forms를 사용하여 대규모 애플리케이션을 개발한 적이 있는지 정말 궁금합니다.

5. 비 오픈 소스 도구를 사용하는 것을 좋아하지 않지만 내 앱의 50% 이상이 syncfusion 도구를 사용한다는 점을 인정해야 합니다. Syncfusion이 없으면 엔터프라이즈 작업 응용 프로그램을 얻는 것이 매우 어렵다고 생각합니다. 그들은 xamarin이 없는 것 또는 xamarin buggy가 무엇인지 모든 것을 가지고 있습니다. 예를 들어, 드래그 앤 드롭, 스와이프 뷰, 선형 및 그리드 레이아웃, 더 나은 가상화 등을 갖춘 수년 동안 sfListView 대체품을 찾았습니다. 마침내 xamarin이 CollectionView와 함께 나왔고 Listview의 "멋진 버전"으로 우리 얼굴에 던졌습니다. 버기다. Uwp에서 작동하지 않습니다. 많은 누락된 기능. 문제 내에서 CollectionView를 검색하기만 하면 수십 개의 문제가 표시됩니다.

나는 여전히 Xamarin이 크로스 플랫폼을 위한 최고의 도구라고 믿고 있으며 그들이 이 문제를 건설적인 피드백으로 받아들이기를 바랍니다.

지금까지 훌륭하고 건설적인 의견. 나는 목록을 읽고 있었고 다른 개발자들과 같은 느낌을 받았습니다. 문제는 Xamarin.Forms를 사용하여 엔터프라이즈 앱을 개발하는 사람들에게 일반적입니다. 버그 추적 및 수정에는 더 많은 주의가 필요하지만 특히 한 가지 분명한 점은 Xamarin.Forms를 사용하여 구축된 엔터프라이즈 MS 응용 프로그램이 없는 이유를 스스로에게 여러 번 묻었습니다. MS 팀 또는 기타. 대답이 Xamarin.Forms를 사용하는 것이 복잡하거나 불가능한 경우 플랫폼 전체를 개선하고 이러한 문제를 해결하기 위한 훌륭한 내부 통찰력이 있습니다. Xamarin/MAUI는 더 많은 개발자가 테스트하고, 기여하고, 소문을 퍼뜨리면 확실히 얻을 수 있지만 이것은 양방향 거리여야 합니다. 다시 말하지만, 나는 불평하지 않지만 올해, 내년에 MAUI 또는 Xamarin으로 빌드된 모바일 애플리케이션의 훌륭한 MS 릴리스를 보게 되면 정말 기쁠 것입니다. 또한 개발자의 불만이나 가능한 개선 사항을 확인하고 플랫폼 간 개발을 새로운 수준으로 끌어올리십시오.

언급했으니까...

저는 Android와 WPF(Windows Desktop) 간의 크로스 플랫폼 애플리케이션을 위한 소규모 프로젝트를 이끌고 있습니다.

우리는 많은 버그를 발견했고, 우리는 일을 하거나 수정해야 했습니다. 현재, 우리의 솔루션을 공유하는 것은 느린 진행이 불가능하기 때문에 수정 및 성능 개선을 위한 내부 프로젝트를 시작합니다. 우리는 또한 데드 라인이 있습니다.

공식 파이프라인에 버그를 가져오는 것은 소규모 팀에게 정말 비용 이 많이 좋습니다 .

xamarin의 wpf 부분에서 할 일이 많습니다. 성능은 나쁘고 단순한 버그의 지옥입니다. 그러나 이면의 아이디어와 기반은 설정되어 있습니다. 현재 상태를 보면 안타까워요...

품질은 항상 Xamarin 개발의 모든 측면에서 문제였습니다. 여러 번 구성 요소 간의 비호환성, VS에서 작동하지 않는 빌드 또는 새 버전의 Forms로 업데이트한 후 내 앱이 충돌하기 때문에 좌절감을 느낍니다. 물건이 작동해야 합니다. 일부 컨트롤이나 레이아웃이 단순히 함께 잘 작동하지 않기 때문에 세 번째로 레이아웃을 다시 작성해야 하는 것은 아닙니다.

몇 가지 관련 포인트가 보입니다.

1. 얼마나 많은 사람들이 Forms에서 작업하는지 모르지만 제가 보기에는 팀이 너무 작아서 새로운 버그나 PR의 빠르게 성장하는 속도를 따라잡을 수 없는 것 같습니다. Forms와 Maui 사이에 주의를 분산시켜야 하므로 상황이 더욱 악화될 것입니다. 팀이 곧 상당한 발전을 이루기를 진심으로 바랍니다.
2. Microsoft가 실제로 자체 앱에서 Forms를 사용하기 시작했다면 정말 도움이 될 것입니다. 단순한 데모나 회의 앱을 말하는 것이 아닙니다. Teams 또는 Outlook과 같은 실제 앱을 의미합니다. 내가 이것에 대해 틀렸다면 기쁠 것입니다. 그러나 상점에서 MS Forms 앱을 찾지 못했고 이 트윗과 같은 일부 출처에 따르면 https://twitter.com/safaiyeh/status/1219294459298344961 그들은 주로 반응합니다. 토종의.

• MS가 자체 기술(XF)을 사용하지 않으면 왜 우리가 사용해야 하기 때문에 이것은 좋은 신호를 보내지 못합니다.
• 복잡한 앱에서 내부적으로 Forms를 사용하면 추가 테스트 계층이 될 수 있으며 공개 릴리스에 영향을 미치는 문제의 수를 줄일 수 있습니다. 또한 그들은 Forms로 작업하는 것이 그들이 말하는 것만큼 쉽지 않다는 것을 알 수 있었습니다.

1. MS가 Win UI Xaml과 같이 이미 입증된 기존 솔루션을 사용하는 대신 XF Xaml의 형태로 계속해서 바퀴를 재발명하려고 한다는 사실에서 또 다른 문제가 보입니다. 그들은 이미 존재하는 기능을 개발하고 그로 인해 도입된 버그를 수정하는 데 시간을 투자해야 하며 다른 기능 및 버그 수정을 위한 시간이 줄어듭니다.

나는 당신이 언급한 많은 문제에 동의합니다. Microsoft는 Xamarin Forms 또는 iOS 또는 Android를 사용하여 엔터프라이즈 앱을 만들어야 합니다. 일단 작동하는 엔터프라이즈 앱 예제가 있으면 전문 앱을 만드는 것이 실망스럽다고 불평할 수 없습니다.

Xamarin Forms는 앱을 한 번 만들고 모든 곳에서 작업하려는 사람들을 위한 훌륭한 플랫폼 간 프레임워크입니다. 간단한 앱을 만들면 잘 작동합니다. 그러나 애니메이션, 분할된 탭, 데이터 가상화, 복잡한 레이아웃 등과 같은 더 많은 기능을 사용하여 보다 전문적인 앱을 만들기 시작하면 기능을 작동시키기 위해 프레임워크와 점점 더 싸워야 하는 자신을 발견하게 됩니다. 작동해야 하는 간단한 작업이 명확하지 않거나 작동하려면 해킹이 필요하다는 것을 알았습니다.

Xamarin Hot Reload와 같은 기능은 개발 단계에서 아직 시기상조입니다. 예를 들어, App.xaml에서 스타일을 변경하거나 App.xaml에서 참조하는 리소스 사전(내 스타일과 리소스를 저장하는 곳)을 만들면 Hot Reload는 시뮬레이터에서 앱의 레이아웃을 엉망으로 만들거나 충돌하는 앱.

Visual Studio는 Xamarin 앱을 개발할 때 엄청나게 버그가 많습니다. 예를 들어 내 Android 프로젝트를 시작 프로젝트로 선택하고 테스트한 다음 iOS 프로젝트를 시작 프로젝트로 전환하면 모든 종류의 잘못된 오류가 표시됩니다. bin 또는 obj 폴더를 파괴해도 도움이 되지 않습니다. VS를 다시 시작해야 합니다. 다른 예에서 VS는 내 앱을 디버깅하는 동안 내 Mac에 대한 연결이 무작위로 끊어집니다. 내 VS가 정지됩니다. 화를 내고 취미와 모바일 개발자로서의 삶에 의문을 제기하고 작업 관리자를 사용하여 VS를 강제 종료합니다. 또한 Visual Studio의 향후 버전에는 이전 버전에서 수정된 버그가 다시 도입됩니다. 최신 버전이 출시된 후 이전 버전의 VS를 설치하는 방법을 몰라서 설치합니다. 제거하고 설치 프로그램을 사용하여 다시 설치할 수 있지만 항상 최신 버전을 설치합니다. 모든 버전을 설치할 수 있는 NuGet 패키지와 다릅니다.

마지막으로 분할된 탭 컨트롤이 이미 Xamarin 도구 키트의 일부가 아닌 이유는 무엇입니까? 세그먼트 탭은 거의 모든 곳에서 사용됩니다. 너무 일반적인 컨트롤을 사용하기 위해 Syncfusion 툴킷이나 다른 툴킷을 사용할 필요가 없습니다.

Xamarin 및 Visual Studio를 사용하여 이러한 개발자의 많은 좌절이 해결될 때까지 내가 개발하는 모든 전문 앱에서 MAUI를 사용하여 채택하는 것이 긴장됩니다. 나오면 플레이해보고 실험하겠습니다. 하지만 마이크로소프트가 나와서 단순한 데모 앱이 아닌 MAUI를 활용한 엔터프라이즈 앱을 만든다면 더 믿음이 갈 것입니다.

누군가 Xamarin Forms 및 MAUI 로드맵에 대해 알려줄 수 있습니까? 병렬로 유지됩니까? Xamarin Forms 지원에 대한 중단이 있습니까? Microsoft는 향후 Visual Studio 업데이트에서 MAUI를 목에 걸 것입니까?

감사합니다

@SunnyMukherjee FAQ에서,

Xamarin.Forms의 미래는 무엇입니까?

Xamarin.Forms의 다음 주요 버전은 2020년 9월경에 .NET MAUI(.NET 6 포함) 릴리스를 통해 계속 업데이트됩니다. 그 후에도 Xamarin.Forms는 12개월 동안 우선 순위 서비스를 계속 받게 됩니다.

기본적으로 Xamarin.Forms는 버전 5 이후에 종료됩니다.

@SunnyMukherjee FAQ에서,

Xamarin.Forms의 미래는 무엇입니까?

Xamarin.Forms의 다음 주요 버전은 2020년 9월경에 .NET MAUI(.NET 6 포함) 릴리스를 통해 계속 업데이트됩니다. 그 후에도 Xamarin.Forms는 12개월 동안 우선 순위 서비스를 계속 받게 됩니다.

기본적으로 Xamarin.Forms는 버전 5 이후에 종료됩니다.

2021년 중반까지 . . . 그 전에 Covid가 나를 죽이지 않는다면 Maui 또는 Xamarin Forms가 그 일을 할 것입니다.

@SunnyMukherjee 나는 당신의 고통을 듣고 있습니다. 저는 Xamarin.Forms가 처음 나왔을 때부터 사용해 왔으며 그 이후로 계속 발전해 왔습니다. Microsoft는 Xamarin.Forms를 만들지 않았으며 2018년에만 Xamarin을 구입했음을 기억하십시오. 따라서 MAUI는 더 나은 상태로 다시 작성하고 전체 .net에서 원활하게 작동하도록 하는 Microsoft의 프로젝트입니다. Xamarin.Forms로 작업하는 것은 사소한 일이 아니기 때문에 사소한 일이 아닙니다. 많은 사람들이 Uno 또는 Flutter가 수행한 작업을 수행하고 컨트롤 자체를 완전히 만들어야 한다고 말합니다. 그러나 이는 Xamarin.Forms에 반대입니다. 네이티브 개발 프레임워크 - 일반적인 방식으로 네이티브 컨트롤을 노출합니다. 이것은 작은 작업이 아닙니다. 또한 Xamarin.Forms에 대해 많은 문제가 있었지만 여러 언어로 동일한 앱을 작성하는 대신 이를 사용하여 절약한 시간이 문제보다 훨씬 큽니다. 또한 백엔드 ASP.Net 핵심 프로젝트와 코드의 90%를 공유할 수 있어 훨씬 더 가치가 있습니다.
MAUI에서 우리가 원하는 것을 Microsoft에 알리는 것이 중요하지만 Microsoft에게 이것이 작은 일이 아니라는 것을 이해해야 하며 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년 9월부터 2021년 11월까지 문제 해결에 더 집중할 수 있습니다.

이것은 스프린트 프로젝트 보드 에서 모두 볼 수 있습니다.

간단히 말해서:

• 커뮤니티 풀 리퀘스트를 더 빠르게 처리하세요.

나는 며칠 전에 풀 리퀘스트 트리를 기반으로 했다. 리뷰가 왜이렇게 오래걸리나요?

WPF-Renderer, 잠재적 버그 포인트:

• 컨트롤의 측정/배열
• Logical/Visual-Childtree가 손상되었습니다.
• 성능

@davidortinau 님 , 이 문제를 해결하는 좋은 방법은 공개적으로 누군가를 완전히 참여하도록 하는 것입니다.

• 버그 문제 분류
• PR 검토 및 병합을 위해 관리, 파견 및 푸시합니다.

그/그녀는 문제가 너무 느리게 진행되는 경우 우리의 연락 담당자가 되어 진행 상황을 설명할 수 있습니다.
또한 법적 장애가 없는 경우 누군가가 버그를 수정하거나 온라인으로 PR을 검토할 수 있는 Twitch 채널을 가질 수 있다면 환상적일 것입니다. IHMO, 이것은 외부 개발자의 관심과 협업에 엄청난 영향을 미칠 수 있습니다.
이는 .NET MAUI 및 Xamarin Forms에 모두 유효합니다. 하지만 나는 단지 몽상가일 수도 있습니다 😄

Xamarin.Forms가 실행 중인 플랫폼의 수와 플랫폼 또는 자체 개발의 변경 사항을 고려하면 Xamarin.Forms에 많은 버그가 있다는 사실은 그다지 놀랍지 않습니다.

저에게 놀라운 것은 회귀 버그의 수입니다. 이전에 작동했거나 이전에 수정된 후 다음 릴리스에서 중단된 것입니다.
나에게 이것은 충분히 테스트하지 않았다는 명백한 신호입니다. 엄격한 테스트 체제는 다음 릴리스에 없는 일부 변경 사항으로 이어질 수 있지만 솔직하게 말하면 신뢰할 수 없는 제품의 낙인을 피하기 위해 조기에 잡는 것이 정말 필요합니다.

더 많은 테스트는 MAUI용 Xamarin.Forms에서 얻은 교훈으로 보고 싶은 것입니다. 버그가 있는 코드가 생성된 PR로 즉시 해결되는 대신 오랜 시간이 걸렸기 때문에 보고된 많은 문제와 리소스 낭비를 피할 수 있습니다.

내가 "핵심 기능"과 "중요한 버그"라고 말했을 때. 이것이 이와 같은 문제를 의미합니다. 이것은 지금 매우 성가시다. 이 문제를 실제로 알지 못한 채 일주일 동안 릴리스를 수행했습니다. 앱 유지율이 급격히 떨어진 이유가 궁금했습니다. 내가 대부분 영어가 아닌 사용자이고 스페인어 또는 독일어 사용자가 앱을 열었는데 이 버그 때문에 영어라고 상상해 보세요. 내 앱이 해당 언어로 번역되더라도 그는 즉시 앱을 제거할 것입니다. 이 버그가 발생할 수 있지만 마운트 전에 보고되었습니까? 왜 수정되지 않았습니다. Appcenter 및 Azure Pipelines에도 해당 버그가 있습니다.

프레임워크를 개선합니다. 추가하고 싶습니다:

자신의 렌더러를 작성할 가능성을 높입니다. internal 키워드를 사용하지 마세요.

Microsoft는 GitHub에 샘플 프로젝트를 게시하는 대신 Xamarin Forms, iOS 또는 Android를 사용하여 OneDrive 또는 Xbox 앱과 같은 전문 엔터프라이즈 앱을 만들고 개발자가 아닌 사람들이 사용할 수 있도록 App Store에 게시할 수 있습니다. Microsoft는 이전에 Visual Studio를 C++에서 C# 및 WPF로 마이그레이션하여 이를 수행했습니다(이 경우 고객이 개발자임을 허용함). 이는 Microsoft에 우리의 고충에 대해 알려줄 것이며 성공할 경우 개발자 커뮤니티에 Xamarin으로 모든 것이 가능하다는 엄청난 확신을 줄 것입니다.

이것에 대한 게시물이 있다는 것이 기쁘고 내 좌절감에 무게를 달고 싶습니다. 나는 종종 기존 문제에 대한 답변을 게시하는 데 수동적이지만, 나를 촉발시키는 것은 BundleAssemblies 와 관련된 이 문제 입니다. 이 큰 영향을 미치는 문제가 발생한 지 2개월이 넘었지만 Xamarin 구성원의 솔루션, 상태 또는 경로에 대한 명확한 표시가 없습니다.

저는 Agile Scrum 팀을 운영하고 있으며 KPI는 Velocity(완료된 작업량)인 경우가 많습니다. 때때로 문제가 특정 수준까지 올라갔을 때 내 결론은 항상 "... 나는 여기에서 " [우리 제품]의 품질을 향상시키기 위해 무엇을 배울 수 있는지 궁금합니다. 실례가 되지는 않지만(정말로) 그것은 단지 내 상사나 고객을 애용하는 것입니다. 그런 종류의 토론 상황에서 내가 말할 때 그것은 단지 나 또는 내 제품 소유자가 일을 하지 못하거나 우리가 여전히 거부 또는 최악의 상태에 있다는 것을 의미합니다. 우리는 무슨 일이 일어나고 있는지 정말로 모릅니다. (저의 감각을 때린 이해 관계자 중 한 명에게 감사)

저를 정말 괴롭히는 것은 회귀 버그와 문제에 대한 간결한 응답/설명이 없다는 것입니다. 모든 XF 릴리스는 무언가를 깨뜨리는 경향이 있습니다. 정렬 오류, 이미지가 표시되지 않음, 텍스트 잘림이 작동하지 않는 등 명백한 것을 깨뜨립니다. 테스트 케이스의 절반은 이러한 XF 회귀를 확인하기 위한 것입니다. 어이가 없네. 분명히 XF 내부 테스트에 문제가 있습니다. 쇼 스토퍼 버그 가 확인된 경우에도 여전히 몇 가지 후속 새 릴리스가 있을 수 있습니다. 우리가 그것을 사용할 수 없을 때 그 새로운 릴리스의 요점은 무엇입니까? 새 릴리스가 베타에 포함되어야 하지 않습니까?

이 모든 것을 말했지만 나와 우리 이해 관계자는 XF의 "독성 문화"에 대해 매우 지쳤습니다. Windows 10이 사용자의 파일이나 벽돌 사용자의 시스템을 삭제하는 업데이트를 릴리스할 수 있는 방법과 같습니다(하지만 최소한 응답 및 핫픽스는 빠름). 여기서 우리의 좌절은 XF의 기능 부족이 아니라 릴리스의 품질에 관한 것이라고 생각합니다. XF가 어떻게 품질을 향상시킬 수 있습니까? 온라인으로 검색하여 수백만 개의 결과를 얻을 수 있습니다. 그리고 "품질 보증"에 대한 Microsoft의 이해를 훼손하지 않고 오만하지 않고 여기에서 어디서부터 시작해야 할지 모르겠습니다. 나는 Microsoft가 품질 보증을 수행하는 방법을 알고 있다고 확신합니다(이에 대해 Microsoft의 백서를 읽었습니다). 그것은 책임자에게 귀결됩니다. 그/그녀는 품질 검사를 개선(또는 구현)하기 위한 책임, 책무성 및 헌신이 필요합니다.

XF와 관련하여 가장 실망스러운 점은 우리의 기여(새로운 PR이든, 새로운 문제이든, 심지어 간단한 질문이나 피드백이든)가 팀에서 무시될 때라고 생각합니다.
팀이 너무 작을 수 있습니다. 그러나 합리적인 시간 내에 답변을 제공하기 위해 전담 한 사람이 있으면 확실히 도움이 될 것입니다.

한 가지 좋은 예는 BundleAssemblies에 대한 회귀입니다 (이미 여러 번 언급되었습니다).
또 다른 좋은 예는 CollectionView에 관한 이 문제 입니다.

저에 대한 또 다른 우려는 XF 앱이 XF의 변경은 물론 Mono, Visual Studio, Xamarin Framework, DotNet 및 일부 Microsoft 라이브러리의 영향을 받는다는 것입니다.
그런 팀들이 내부적으로는 의사소통이 잘 되지 않는다는 느낌이 든다.
제 생각에는 Microsoft가 앱에 내부적으로 XF를 사용하는 것이 확실히 도움이 될 것입니다.

다시 말하지만, 한 가지 좋은 예는 이 회귀 이며, 근본 원인은 실제로 Mono 및 AndroidX에 있습니다.
그러나 iOS 앱에 영향을 미치는 dotnet 확장 프로그램에서 이 문제 를 언급하거나 msal에서도 이 문제 를 언급할 수 있습니다.
물론 소스 링크와 관련하여 Visual Studio의 이 문제 도 마찬가지입니다 .

여기 사람들이 내가 하려고 하는 대부분의 세부 사항을 훌륭하게 설명했으므로 빨리 말하겠습니다.

기술적 문제

• Visual Studio는 XF로 작업할 때 분당 3번 이상 충돌합니다.
• 기본 컨트롤이 많이 없거나 원래대로 모양을 만드는 데 지옥이 필요합니다.
• XF가 최악의 성능 크로스 플랫폼 프레임워크라고 말할 때 XF가 기본 Android/ios를 다루며 어렵다고 말하는 사람들을 위해 분명히 하겠습니다. 그냥 봐! 봐주세요! 신의 사랑을 위해! at flutter, RN, NativeScript... 모두 같은 목표를 가지고 있지만 XF는 훨씬 뒤쳐져 있습니다.
• 핫 리로드는 새 프로젝트를 만들고 왼쪽에 기본 텍스트를 만들 때만 잘 작동합니다.
• 모든 릴리스에서 Flutter 커뮤니티의 모든 사람들은 다음과 같이 말합니다. 오오오 정말 멋진 일을 하고 있습니다. 반면에 XF 컴은 다음과 같습니다. 컴의 10%만 필요로 하는 고장이나 추가한 것을 봅시다!
• XF를 사용하는 시작 여정은 지옥의 연속입니다. 예를 들면 다음과 같습니다. 최근에 Playstore의 모든 앱에서 공통 컨트롤 중 하나를 만들어야 했습니다. 이 컨트롤은 단순한 하단 탭 아이콘뿐입니다. 보기 흉하고 모두처럼 보이는 맨 아래에 문제를 만들었습니다. 비슷한 문제가 6개월 이상 전에 해결되었다는 것을 알았습니다... 그리고 도중에 수정이 없었습니다.
• 앱이 생각나세요? 어떤 앱? 인앱 구매 또는 일종의 프리미엄 서비스가 있습니까? 물론 그렇습니다. 그래서 당신은 구글 페이와 애플 페이를 위한 플러그인을 찾기 시작했습니다. 맞습니까? 아니면 페이팔도 맞나요? 내가 당신에게 뭔가를 말하자, 거기에 없습니다 !!! XF 공식 팀에 물어보면 뭐라고 대답할지 아세요? 그들은 당신에게 업데이트 없이 2년 전에 한 사람(내가 존경하는)이 만든 구식의 비공식 플러그인에 대한 링크를 보냅니다. WTF(죄송합니다) !!

기술적이지 않음

• Oh comme ooon 심지어 공식 문서는 매우 열악합니다. 그들은 할 일 앱 수준 기능과 방법 자습서를 다룹니다.
• 나는 XF를 사용하기 전에도 싫어했는데 왜 그런지 알아? 다들 MS도 안쓰는데 왜 F를 쓰냐?
• 커뮤니티가 XF 팀을 돕기 위해 자신의 시간과 비용으로 만드는 문제 및 PR에 대한 매우 느린 응답 !!!

솔루션

• XF 팀은 매우 작습니다. Microsoft가 자체 제품을 개선할 만큼 충분한 인력을 고용하지 않는데 어떻게 회사가 거대할 수 있습니까? 나만큼 Microsoft를 사랑하는 인재들이 전 세계 어디에나 있습니다!
• XF는 출시하기 전에 높은 수준의 문제를 해결해야 합니다. 팀이 얼마나 미성숙한지 보여줄 뿐입니다.
• 마이크로소프트는 대부분 그들의 제품에 XF를 사용할 의무가 있습니다! XF가 좋다는 식으로만 표현하는 것이 아니라면 싫지만요 yukh
• 매우 풍부한 문서를 만드십시오! 대부분의 상황에서 가장 먼저 이동하는 문서는 더 많은 사람을 고용하십시오! 그것만큼 쉽습니다. 블로그에 함께 일할 수 있는 경험 많은 개발자가 있습니다.
• XF는 Flutter만큼 많이 알려져 있지 않습니다. YouTube에서 큰 코딩 인플루언서와 파트너십을 맺으세요. 간단한 언급만으로도 XF에 도움이 됩니다.
• 다른 제품을 살펴보고 개발자가 제품에 대해 어떻게 생각하는지 확인하고 자신만의 버전을 만드십시오. 예를 들어 플러터.
• 커뮤니티에 그들이 원하는 것을 묻는 것을 두려워하지 마십시오. 바위 아래에서 살지 말고 아무도 사용하지 않을 것을 만드십시오!

내 공격적인 행동과 나쁜 영어에 대해 매우 유감스럽게 생각합니다. 저는 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 ;) (항상 늦거나 불완전함)
다시 말하지만, XF에 대해 구체적으로 말하는 것이 아니라 일반적으로 전체 xamarin 프레임워크(xamarin.android, xamarin.ios, Visual Studio, mono, components...)에 대해 이야기하고 있습니다.

다음은 예입니다. xamarin ios 릴리스 정보

@멜리미온

성능을 향상시키는 새로운 기능을 추가하면 정말 좋습니다! 그러나 이러한 기능을 사용할 수 없을 때는 매우 실망스럽습니다.

이것은 절대적으로 사실입니다.
CollectionView를 추가했습니다. 그 결과 Android에서는 많은 오류가 발생하고 iOS에서는 일반적으로 사용할 수 없습니다(Disposed 예외, NSinconsistency 예외 등. 그리고 이것은 공식 가이드(!)에 따라 모든 작업을 수행하는 경우입니다.
CarouselView를 추가했습니다. 오류는 동일합니다.
우리는 오래되었지만 더 안정적인 Listview를 사용해야 합니다.

이제 "추가했습니다"라는 제목이 표시되면 즉시 더 스크롤합니다.
예를 들어 다른 요소도 있습니다.
Swipeview,Expander도 오류가 많습니다.
그리고 위에 사람이 쓴 것처럼 자체 버그가 있는 모노, Visual Studio가 있습니다.

4.7-4.8의 새로운 기능을 취소하고 버그 수정에 주의하십시오.
Xamarin에서 개발은 해결 방법, 임시 솔루션을 찾는 것과 같습니다.
서투른 영어에 대해 사과드립니다.

어제 확인했습니다. 영향력이 높은 것으로 표시된 문제가 200개 이상 있습니다. 중요한 버그가 아직 해결되지 않은 상태에서 새로운 기능을 출시하는 것은 의미가 없습니다. 이전 제안에 동의합니다. 새로운 기능을 중지합니다. 시간을 내어 문제를 수정하고 수를 줄이십시오. 예를 들어 문제로 인해 4.4에서 멈췄습니다. 이 상황에 훨씬 더 많은 사람들이 있다고 상상해보십시오. 혁신과 유지보수를 할 인력이 없다면 안정성과 성능이 우선입니다.

기존 버그를 제거하거나 4.7 이상에 계획된 기능을 추가하기 위해 엔지니어링 노력을 기울이는 것이 더 좋은지 알아보기 위해 XF 개발자들 사이에서 일종의 설문조사가 있을 수 있는지 궁금합니다. 내 말은 새로운 기능 자체가 더 많은 재작업과 더 많은 지연을 유발하는 더 많은 새로운 버그를 추가할 것이라는 것을 의미합니다... 때때로 좋은 구식 기능 동결이 요구됩니다.

개인적으로 XF 아키텍처의 합리적인 재설정처럼 들리는 MAUI에 가장 많은 노력을 기울이고 두 번째로 큰 영향을 미치는 버그를 제거하는 데 가장 많은 노력을 기울이는 것을 보고 싶습니다. 새로운 기능을 추가하는 것은 내 목록에도 포함되지 않습니다. 추가할 더 나은 플랫폼이 있을 때 추가하고 싶습니다.

@freever 전적으로 동의합니다!
이것은 현재 Xamarin 개발자를 더 행복하게 만들 뿐만 아니라 MAUI에 대한 이러한 버그도 해결할 것입니다!

이러한 버그가 여기 MAUI에서 수정되도록 수행될지 아니면 Xamarin.Forms에서 수정될지 모르겠습니다.

@davidortinau 가 이 문제의 핵심을 여기에서 다룬 것 같습니다.

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

나는 그의 의견으로 설명을 업데이트했습니다.

나는 그가 모든 사람을 위해 다시 한 말의 이 부분을 강조하고 싶습니다.

현재 스프린트의 대부분을 CollectionView 문제에 소비하고 있으며 Xamarin.Forms 5의 기능 개발자를 일시 중지하여 2020년 9월부터 2021년 11월까지 문제 해결에 더 집중할 수 있도록 할 것을 제안합니다.

PureWeen은 10시간 전에 닫았습니다.

수십 명의 xamarin 개발자가 이 티켓에 자신의 의견을 표명했으며, 나는 그들이 들었다는 느낌이 들지 않습니다.
슬프게도, 당신은 내 요점을 증명했습니다

@PureWeen 이 문제는 버그의 수 이상을 다룹니다. 그들은 심지어 포인트 형태로 나열됩니다.

@tranb3r

XF와 관련하여 가장 실망스러운 점은 우리의 기여(새로운 PR이든, 새로운 문제이든, 심지어 간단한 질문이나 피드백이든)가 팀에서 무시될 때라고 생각합니다.

@davidortinau 의 의견이 어떻게 당신에게 부족합니까? 내가 말하고 있는 요점은 우리가 공개 PR과 버그에 더 집중할 수 있도록 새로운 기능에 대한 개발 속도를 늦추고 결국 우리의 최신 .net 6 기반 제품이 될 .net maui에 도달할 수 있다는 것입니다.

@Happypig375

@pauldipietro 는 해당 문제를 게시한 개인에게 연락하여 해당 문제를 더 직접적으로 해결할 수 있도록 했습니다.

이 문제의 핵심은 XF에 버그가 너무 많고 커뮤니티를 무시한다는 것입니다. 따라서 기존 버그와 공개 PR에 더 집중하기 위해 새로운 개발 속도를 늦추고 있습니다.

공개된 버그 외에 다른 문제가 있는 경우 해당 문제에 대해 공개해 보겠습니다. 그러나 이 문제는 너무 많은 미해결 버그에 관한 것이며 우리는 이를 해결할 계획이 있습니다.

MAUI를 사용하면 가능한 한 빠른 버그 수정 프로세스가 있어야 합니다. 개선 방법에 대한 생각이 있습니까?

우리는 .NET Maui를 사용하여 Form에서 많은 레거시 측면을 제거하고 있으며 .NET Maui로 생산성을 높일 수 있도록 버그와 공개 PR에 집중적으로 집중하기 전에 올해를 보낼 것입니다.

이것은 우리의 프로젝트 보드입니다.

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

우리가 각 스프린트에 추가하는 것을 볼 수 있습니다
https://github.com/xamarin/Xamarin.Forms/projects/70

다음은 로드맵입니다.
https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap
우리는 우리가 하고 있는 일을 최대한 투명하게 하려고 노력합니다

해당 리포지토리의 문제가 핑(ping)을 받거나 집중도가 높은 경우 상위에 버블링을 시도하지만 때로는 해당 알고리즘이 완벽하지 않을 수 있습니다.

@Amine-Smahi 여기 셸용 프로젝트 보드와 우리가 차단기로 보는 것이 있습니다.
https://github.com/xamarin/Xamarin.Forms/projects/54

제가 살펴볼 수 있도록 말씀하신 문제를 알려 주시겠습니까?

@PureWeen

@davidortinau 의 의견이 어떻게 당신에게 부족합니까? 내가 말하고 있는 요점은 우리가 공개 PR과 버그에 더 집중할 수 있도록 새로운 기능에 대한 개발 속도를 늦추고 결국 우리의 최신 .net 6 기반 제품이 될 .net maui에 도달할 수 있다는 것입니다.

앞서 언급했듯이 이 문제는 XF의 버그 수 그 이상을 다룹니다.

공개된 버그 외에 다른 문제가 있는 경우 해당 문제에 대해 공개해 보겠습니다. 그러나 이 문제는 너무 많은 미해결 버그에 관한 것이며 우리는 이를 해결할 계획이 있습니다.

이미 너무 많은 미해결 문제가 있습니다 !!! 그냥 무시하고 새로 여는 게 무슨 소용이야...

예를 들어 앞에서 언급한 중요한 사항 중 하나는 Microsoft 팀이 앱을 개발할 때 xamarin을 사용해야 한다는 것입니다.
이 피드백이 들리나요? 이것이 좋은 생각이라는 것을 당신에게 확신시키려면 어떻게 해야 합니까? 우리는 그것에 대한 문제를 열어야합니까 ???

앞서 언급했듯이 이 문제는 XF의 버그 수 그 이상을 다룹니다.

이를 위해 다양한 문제를 만들어 보겠습니다. 여러 가지를 하나의 문제로 해결하는 것은 생산적이지 않을 것입니다.

XF에 대한 공개 버그/prs/취약성 문제와 관련이 없는 다른 의견은 무엇입니까?

예를 들어 앞에서 언급한 중요한 사항 중 하나는 Microsoft 팀이 앱을 개발할 때 xamarin을 사용해야 한다는 것입니다.
이 피드백이 들리나요? 이것이 좋은 생각이라는 것을 당신에게 확신시키려면 어떻게 해야 합니까? 우리는 그것에 대한 문제를 열어야합니까 ???

예, 말 그대로 모든 사람이 Xamarin을 사용하도록 설득하려고 합니다.

우리는 앱 선택에 대해 내부 팀과 많은 이야기를 나누며 현재 진행 중인 논의입니다. 이러한 내부 토론의 대부분은 .NET Maui의 방향을 안내할 것입니다.

나는 이것에 대해 무엇을 더 논평할 수 있는지 잘 모르겠습니다. 특별히 사용자를 돕기 위해 제가 할 수 있는 조치는 많지 않습니다.

@PureWeen 이 문제의 핵심은 XF에 버그가 너무

따라서 잠시 동안 버그 수정 속도가 약간 더 빨라질 것으로 예상합니다. 좋긴 하지만 이 문제를 완전히 해결하지는 못합니다. XF를 베타 품질에서 안정 상태로 만드는 것은 매우 큰 작업이며 빠른 수정이나 단일 전략으로는 이를 달성할 수 없습니다. 조직적, 철학적, 구조적 변화가 필요합니다. 내가 제안 할게:

1. 리포지토리 를
2. 기능보다 버그 수정 및 정리 코드를
3. 버그를 수정하고 코드를 정리하는 주요 변경 사항 을
4. .Net 을
5. 가장 기본적인 컨트롤을 먼저 수정 한 다음 나머지 컨트롤을
6. Jettison 이전 대상 OS 및 이전 편집자 는 리포지토리를 정리하고 테스트를 간소화하며 버그 수정을 위한 리소스를 확보합니다.
7. 공개적으로 버그 메트릭에 대해 보고합니다. 이는 조직이 버그에 집중하는 데 도움이 됩니다. 업데이트에 대한 모든 블로그의 첫 번째 섹션으로 버그 진행 상황을 기록하세요.
8. 기능 을

우리의 경험: 우리는 사용할 수 있는 다른 것을 신뢰하지 않기 때문에 기본 XF 보기만 사용합니다. Label, Entry, Button, Picker, Switch, DatePicker, Slider, StackLayout, ScrollView, ContentView, Grid, ContentPage. 그러나 그때에도 버그가 발생하여 몇 달 동안 남아 있습니다. XF에 수정 사항을 적용하는 것은 너무 어렵기 때문에 대신 렌더러를 복사하여 코드에 붙여넣습니다.

리포지토리를 단순화하여 더 쉽게 기여하고 기여를 검토할 수 있습니다. 새로운 렌더러 아키텍처는 코어에서 XAML을 대체하고 렌더러에 보다 유형이 안전한 접근 방식을 제공하는 경우 도움이 될 수 있습니다.

그것이 우리의 계획입니다. https://github.com/dotnet/maui/issues/147 팔로우하거나 제안할 수 있는 자리 표시자 문제를 만들었습니다.

기능보다 버그 수정 및 정리 코드를 우선시하십시오. Xamarin의 문화는 버그를 무시하고 새 기능을 추가하는 것이므로 기존 기능의 품질 임계값이 충족될 때까지 새 기능을 완전히 금지하는 것이 가장 좋은 방법입니다.

이것은 대부분 우리의 계획입니다.

버그를 수정하고 코드를 정리하는 주요 변경 사항을 허용합니다.
.Net을 최대한 활용하여 버그를 줄이십시오. 가능한 한 유형 시스템 내부에 보관하고 C# 8 NRT를 채택하십시오.

이것은 천천히 우리의 계획입니다. 그러나 우리 제품을 사용하는 사용자의 전체 범위를 이해하는 것이 중요합니다. 예를 들어 vs2017 지원을 중단한 후 사용자로부터 수많은 의견을 받은 이 문제가 여기에 나타납니다.
https://github.com/xamarin/Xamarin.Forms/issues/7602

그래서 우리는 점프를 할 수 없습니다. 나는 100% 그 도약을 하고 싶지만 사람들을 무너뜨릴 수는 없습니다.

그러나 우리는 이러한 도약에 대비하기 위해 지속적으로 조치를 취하고 있습니다. 예를 들어 여기 PR
https://github.com/xamarin/Xamarin.Forms/pull/10937

내부 CI 프로세스를 실행하여 C# 8 및 기타 베타 기능에 대해 테스트할 수 있으므로 일단 도약할 수 있으면 쉽게 도약할 수 있습니다.

가장 기본적인 컨트롤을 먼저 수정한 다음 나머지 컨트롤을 수정합니다.
Jettison 이전 대상 OS 및 이전 편집자는 리포지토리를 정리하고 테스트를 간소화하며 버그 수정을 위한 리소스를 확보합니다.

그것이 위에서 언급한 우리의 계획입니다

공개적으로 버그 메트릭에 대해 보고합니다. 이는 조직이 버그에 집중하는 데 도움이 됩니다. 업데이트에 대한 모든 블로그의 첫 번째 섹션으로 버그 진행 상황을 기록하세요.

이것에 대해 찾고 있습니다. @samhouts 는 매 스프린트마다 이러한 보고서를 많이 실행하므로 모든 것에 대한 관점이 있지만 커뮤니티에 더 잘 노출되도록 조사할 것입니다.

리포지토리의 크기를 줄이는 기능을 제거하여 유지 관리를 더 쉽게 만듭니다.

이것은 .net MAUI에 대한 우리의 계획입니다. .NET MAUI 계획을 시작하기 전에 더 효과적으로 줄이기 위해 줄일 수 있는 영역 목록을 준비했습니다. 이것의 큰 부분은 렌더러 작업이 될 것입니다.

안녕하세요, 언급된 문제 외에도 오른쪽에서 왼쪽으로 언어와 관련된 많은 버그가 있습니다. Xamarin Forms Team의 관점에서 이러한 버그는 덜 중요해 보입니다(아마도 영어나 다른 왼쪽에서보다 오른쪽에서 왼쪽 언어의 사용이 적기 때문일 것입니다. 오른쪽 언어), 오른쪽에서 왼쪽으로 문화에 대한 완전한 지원 부족은 실망스럽고 실망스럽고 실제로 개발자가 국제/다국어/오른쪽에서 왼쪽 앱에서 XF를 사용하지 못하게 합니다.
감사 해요.

다음 2개월 된 문제: https://github.com/xamarin/Xamarin.Forms/issues/11166
버그 생성 6월 22일
PR이 6월 25일에 열렸습니다.
버그 상태 8월 17일: 아직 병합되지 않았습니다. 왜요? ;(

@PawKanarek Xamarin에 오신 것을 환영합니다. 일반적으로 팀에서 만든 수정 사항이나 Prs만 병합합니다. 이것이 Xamarin에 기여하는 것이 낙담되는 이유입니다. 나는 그들이 팀의 능력을 감소시켰다고 생각한다. 2-3명만 프로젝트에 적극적으로 참여합니다. 빠른 수정이 필요한 경우 자체 xamarin nuget 패키지를 빌드하세요.

@EmilAlipiev 하지만 이번에는 PR(#11166용)이 Xamarin 팀 구성원에 의해 열렸지만 아직 병합되지 않았습니다.

릴리스 정보와 GitHub 인사이트를 살펴보면 커뮤니티의 수많은 PR을 병합합니다. 사실 최근 명단 에 이름이 보이네요 @EmilAlipiev :)

지난 달 에 18명의 다른 사람이 40개의 새로운 풀 리퀘스트를 열었음을 알 수 있습니다. 풀 리퀘스트는 완전히 테스트되고 검토되어야 하며, 우리가 받는 양에 따라 해결 방법이 없는 차단 문제와 주요 회귀의 우선 순위를 지정해야 합니다.

우리가 항상 완벽하지는 않다는 것을 알고 있지만, 우리는 매일 개선하기 위해 노력하고 있습니다. 기다려 주셔서 감사합니다. 우리는 이것을 함께 할 수 있습니다!

@hamiddd1980 우리가 지난 몇 달 동안 RTL에 대해 꽤 많은 작업을 해 왔다는 사실을 알게 되어 기쁠 것입니다. 나는 그것이 당신의 경험을 향상시키기를 바랍니다!

@samhouts 당신은 Xamarin의 최종 제품이 아니라는 것을 기억하십시오. 인내심 뿐만 아니라 많은 인적 자원과 돈이 필요합니다. github의 모든 공개 및 확인된 버그는 기술 부채, 분노 및 고객과의 불필요한 긴장의 형태로 눈덩이 효과를 생성하므로 최대한 빨리 수정해야 합니다.

더 많은 기능을 추가하지 말고 더 많은 버그를 수정하십시오. 기능보다 안정성. 아직 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개월 이상이 걸렸고 다른 지점에서 rebased로 이 병합을 3번 만들어야 했습니다.
그 외에도 귀하의 우선 순위 문제가 있습니다. 사람들은 Device.Idiom.. 또는 CollectionView 버그와 같은 버그와 같은 핵심 도구에 대한 수정 사항을 필사적으로 찾고 있습니다.
오늘은 지금까지 총 8개의 병합이 실제로 크게 진행되었습니다. 그러나 병합 아래에서 정직하게 말하면 스와이프 보기, 그라디언트 브러시 또는 테마 등에 관심이 있는 사람이 적습니다. 이러한 중요한 PR이 몇 달 동안 대기열에 있을 때입니다. 이것이 내가 믿는 가장 큰 좌절이다.

github의 모든 공개 및 확인된 버그는 최대한 빨리 수정되어야 합니다.

이것은 분명히 비현실적입니다. Microsoft가 Xamarin.Forms 팀 규모를 크게 늘린 경우에도 마찬가지입니다.
그들은 더 열심히 일하지 않고 더 똑똑하게 일한다고 말합니다(이 경우 이는 PR에 회귀 테스트를 포함하여 버그가 다시 나타나지 않도록 해야 한다는 것을 의미해야 합니다. PR은 점점 더 길어질 것입니다).

더 많은 버그를 수정하고 더 많은 기능을 추가하지 마십시오.

이것은 저도 공유하는 의견입니다. 그러나 엄격하게 말해서 MAUI<>Xamarin.Forms 전환 계획은 이미 이를 포함합니다. Xamarin.Forms는 버그 수정 모드로만 전환되고 새로운 기능은 Maui에만 적용됩니다.

(이 경우, 이는 버그가 다시 나타나지 않도록 하기 위해 회귀 테스트를 포함하도록 PR을 요구해야 함을 의미해야 합니다. 그러나 다른 모든 경우와 마찬가지로 기여한 PR에 대한 검토가 점점 더 길어지기 때문에 이것은 또한 절충점입니다.)

전적으로. 이것은 우리도 어려움을 겪고 있는 절충안입니다. 자동화된 수천(!) 개의 테스트가 있으며 여러 장치에서 실행합니다. 문제는 완료하는 데 몇 시간(현재 장치당 실행당 약 4시간)이 걸리고 불행히도 여러 가지 이유로 인해 때때로 약간 불안정하다는 것입니다. 예를 들어, 어제 합법적으로 실패했다고 생각했던 테스트에 대해 기고자에게 핑을 쳤는데, Chrome에서 새로운 서비스 약관에 동의하도록 요청했기 때문에 실제로 실패했다는 것을 깨달았습니다. 🤦

이로 인해 많은 지연이 발생하고 PR이 테스트를 통과하는 데 며칠이 걸릴 수 있음을 의미합니다. 그것은 우리 몫이고, 우리가 해결해야 할 문제입니다.

다행히도 우리는 이 문제를 해결하기 위해 노력하고 있습니다. 우리는 훨씬 더 안정적이고 빠른 UI 자동화보다 단위 테스트에 더 가까운 플랫폼 렌더러를 테스트하는 새로운 방법을 개발하고 있습니다.

새로운 기능을 추가하는 것과 버그를 수정하는 것까지... @knocte가 말했듯이 전환 계획은 이를 염두에 두고 설계되었습니다. .NET MAUI의 목표는 간결하고 빠르며 안정적인 것입니다. 그 일환으로 우리는 어떤 기능이 핵심 프로젝트에 실제로 속하고 어떤 기능이 새로운 Community Toolkit에 더 적합한지 평가하고 있습니다.

변경 사항이 있을 때 항상 귀하와 귀하의 고객을 염두에 두고 있으며 귀하의 피드백에 귀를 기울이고 있습니다.