7049 tardó más de 1 mes en implementarse incluso cuando el RP se fusionó 7 días después del informe de error

Y abrir una solicitud de extracción aún puede resultar en que la solicitud se quede atascada en el limbo hasta que un funcionario de Xamarin se tome el tiempo para echar un vistazo a los archivos modificados.

Con suerte, el equipo tiene un plan para eliminar algunos de los cuellos de botella en torno al proceso de publicación de PR +.

Y abrir una solicitud de extracción aún puede hacer que la solicitud se quede atascada en el limbo hasta que un funcionario de Xamarin se tome el tiempo para echar un vistazo a los archivos modificados.

Y mire eso, después de ser mencionado en un problema de alta visibilidad, alguien del equipo de Xamarin.Forms finalmente respondió a https://github.com/xamarin/Xamarin.Forms/pull/7728.

Y abrir una solicitud de extracción aún puede hacer que la solicitud se quede atascada en el limbo hasta que un funcionario de Xamarin se tome el tiempo para echar un vistazo a los archivos modificados.

Y mire eso, después de ser mencionado en un problema de alta visibilidad, alguien del equipo de Xamarin.Forms finalmente respondió a xamarin / Xamarin.Forms # 7728 .

Siento empatía con el equipo. Muchos problemas no son fáciles de clasificar, gestionar o solucionar. Dicho esto, definitivamente debe haber un enfoque en eliminar los cuellos de botella y eliminar los problemas abiertos y las relaciones públicas.

De acuerdo, la calidad siempre ha sido un problema para todos los aspectos del desarrollo de Xamarin. Muchas veces me siento frustrado debido a las incompatibilidades entre los componentes, no funciona la compilación en VS o mi aplicación se bloquea después de una actualización a la nueva versión de Forms. Las cosas deberían funcionar. No debería verme obligado a reconstruir mi diseño por tercera vez porque algunos controles o diseños simplemente no funcionan bien juntos.

Veo un par de puntos relacionados

1) No sé cuántas personas trabajan en Formularios, pero a mí me parece que el equipo es demasiado pequeño para seguir el ritmo de crecimiento rápido de nuevos errores o relaciones públicas. Esto solo empeorará ya que tendrán que dividir la atención entre Forms y Maui. Realmente espero que el equipo reciba un impulso sustancial pronto.

2) Sería de gran ayuda si Microsoft comenzara a usar Formularios en sus propias aplicaciones. Y no me refiero a simples aplicaciones de demostración o conferencias. Me refiero a aplicaciones reales como Teams o Outlook. Me alegraría si me equivoco en esto, pero no logré encontrar ninguna aplicación de MS Forms en las tiendas y, según alguna fuente como este tweet https://twitter.com/safaiyeh/status/1219294459298344961 , usan principalmente reaccionar nativo.

• esto realmente no envía una buena señal porque si MS no usa su propia tecnología (XF), ¿por qué deberíamos hacerlo?

• El uso de formularios internamente en aplicaciones complejas podría ser una capa adicional de pruebas y podría reducir la cantidad de problemas que llegan al lanzamiento público. Además, pudieron ver que trabajar con Formularios no es tan fácil como nos dicen.

3) Veo otro problema en el hecho de que MS constantemente intenta reinventar la rueda en una forma de XF Xaml en lugar de usar soluciones ya probadas y existentes como Win UI Xaml. Tienen que invertir tiempo en desarrollar funciones ya existentes y en corregir errores que se introducen debido a eso y luego hay menos tiempo para otras funciones y correcciones de errores.

Estoy 100% de acuerdo con @Reveon
Ah, y debo decir que usar VisualStudio para Windows con Xamarin es una experiencia súper frustrante.

Siguen agregando errores pendientes, de bloqueo ... ni siquiera sé cómo es posible (cosas como romper TODAS las compilaciones del dispositivo ios, romper los perfiles de aprovisionamiento, romper el reconocedor de gestos ... cómo pueden los errores como estos entrar en producción y luego ¿Tardará semanas o meses en arreglarse en la versión de lanzamiento? No sé ...)

Cambié a Rider para eso y ahora estoy usando el producto Jetbrains en todas partes :) Al menos puedo usar un IDE que es exactamente el mismo en iOS y Windows y continuar trabajando de manera productiva.

Estoy seguro de que con MAUI esas cosas cambiarán y, tarde o temprano, Microsoft comenzará a usar MAUI internamente para proyectos serios.

Otro testimonio:
https://github.com/xamarin/Xamarin.Forms/issues/10482#issuecomment -633730446
@EmilAlipiev :

He estado esperando que mi RP se fusione durante 1,5 meses para este problema. Ya existe un problema para Ios y Android se solucionó en julio de 2019 y nadie se tocó para uwp. Lo arreglé en abril y solicité varias veces su revisión y fusión. Es realmente molesto cómo están trabajando los equipos de xamarin. Puede ver que solo revisan 1-2 RP por día.
# 10316

Aunque a menudo me siento frustrado, "Xamarin tiene errores" es una declaración dura. Más de 2000 problemas abiertos hoy, si marca que flutter tiene más de 5000 problemas abiertos. Los números no son tan importantes. Xamarin.forms ofrece más que otras plataformas cruzadas como uwp (incluida xbox), wpf, mac, gtk, tizen. Por lo tanto, hay muchos problemas abiertos para Wpf, por ejemplo, que son de menor prioridad para la mayoría de nosotros.
El núcleo de Xamarin.forms debe ser ios, android y uwp, aunque el equipo de Xamarin a menudo descuida uwp.

1. Debería haber elementos centrales como diseños, vistas de lista, carrusel, vista de colección, imágenes, mapas, etiquetas, editor, etc. Esos deberían estar libres de errores. Si realiza una nueva versión o actualiza en ellos, debe asegurarse de que no haya un error espectacular. Si hay un error, debe resolverlo dentro de una semana como máximo. Pero el equipo de Xamarin está lanzando ese genial "4.5-4.6" con características geniales (¿quién necesita esta elegante herramienta el 10% de la comunidad?) Y el control de imagen está roto. El problema se informó a principios de marzo y aún no se ha resuelto hasta el día de hoy. El mismo "Paquete en ensamblados nativos" está roto. Por esas razones cruciales, no puedo actualizar a 4.5 y 4.6. Siguen desarrollándose con 4.7 agregando nuevas características. La mayoría de nosotros y yo estamos atentos a las notas de la versión, ya sea que se resuelvan nuestros errores, ni siquiera leo qué característica se agregó.
2. El equipo de Xamarin tiene que entender esto. La razón principal por la que muchas personas eligen Xamarin es "UWP". Soy autónomo. Le pregunto a mi cliente por qué no revolotear o reaccionar de forma nativa. Dice que porque Xamarin tiene UWP. También quiero UWP. Pero Uwp tiene principalmente errores con Xamarin.forms. introdujeron CollectionView, es realmente genial pero desde hace un año tiene ese error no resuelto. Lo arreglé, nadie está revisando. Me desanimó hacer más contribuciones.
3. Hotreload no funciona en absoluto. Leí en twitter todo "beso beso" lo genial que es hotreaload. Estoy pensando que debería haber algo mal en mí o que usan alguna otra herramienta. Porque a menudo hotreload no se actualiza. Todavía estoy usando herramientas de terceros como livexaml, etc. Incluso creé una aplicación de consola simple para hacer mi propia recarga en caliente. me cuesta 1 día. Funciona mucho mejor que Xamarin e incluso funciona para uwp. ¿Cómo pueden no entregarlo? Tenían livereload estaba funcionando.

4. Punto más importante; lo que @Reveon mencionó. necesitan una aplicación empresarial real que funcione con xamarin.forms y deberían actualizarla con nuevas versiones para detectar problemas reales. Se quejan de que "no es tan difícil dar repro". Sí, es muy difícil si este problema solo ocurre en su aplicación empresarial, no en una aplicación de tareas pendientes. Debe intentar replicar la misma interfaz de usuario. puede costarle sus días hasta que lo averigüe. Por eso es muy importante que haya alguien que tenga una aplicación grande. Realmente me pregunto si alguno de esos desarrolladores de Xamarin que vemos en twitch, youtube, twitter, etc., alguna vez ha desarrollado una gran aplicación con xamarin.forms.

5. Tengo que admitir algo, aunque no me gusta usar herramientas que no sean de código abierto, más del 50% de mis aplicaciones son con herramientas de sincronización. Sin Syncfusion, creo que es muy difícil conseguir una aplicación empresarial que funcione. Tienen todo lo que xamarin no tiene o lo que es xamarin buggy. Por ejemplo, busqué el reemplazo de sfListView durante años con arrastrar y soltar, vista de deslizamiento, diseño lineal y de cuadrícula, mejor virtualización, etc. tiene errores. No funciona para Uwp. muchas características que faltan. Simplemente busque CollectionView dentro de los problemas, terminará con docenas de ellos.

Sigo creyendo que Xamarin es la mejor herramienta para multiplataforma y espero que tomen este tema como una retroalimentación constructiva.

Grandes y constructivos comentarios hasta ahora. Estaba leyendo la lista y me sentía igual que los otros desarrolladores. Los problemas son comunes entre quienes usamos Xamarin.Forms para desarrollar aplicaciones empresariales. El seguimiento y la corrección de errores necesitan más atención, pero especialmente, un punto que está claro, y muchas veces me he preguntado es por qué no hay una aplicación empresarial de MS construida con Xamarin.Forms. MS Teams o cualquier otro. Si la respuesta es: demasiado complicado o imposible de hacer con Xamarin.Forms, hay una gran información interna para mejorar la plataforma en su conjunto y tratar de solucionar esos problemas. Xamarin / MAUI ciertamente se beneficiará con más desarrolladores que prueben, contribuyan y corran la voz, pero esto debería ser una vía de doble sentido. Una vez más, no me quejo, pero sería enorme ver, este año, el próximo año, una gran versión para MS de una aplicación móvil construida con MAUI o Xamarin. También verifique a los desarrolladores por sus frustraciones o posibles mejoras, y lleve el desarrollo multiplataforma a un nuevo nivel.

Porque, me mencionaron ...

Lidero un pequeño proyecto para una aplicación multiplataforma entre Android y Windows Desktop (WPF).

Encontramos muchos errores que tuvimos que solucionar o solucionar. Actualmente, comienzo un proyecto interno para las correcciones y mejoras de rendimiento, porque compartir nuestras soluciones es con este lento avance imposible. También tenemos líneas muertas.

Traer errores en la canalización oficial es realmente costoso para nuestro pequeño equipo, por lo que sería bueno recibir más atención, tal vez obtenga más de la comunidad.

En la parte wpf de xamarin hay muchas cosas que hacer. El rendimiento es malo y es un infierno de errores simples . Pero la idea detrás y la base está puesta. Es triste ver el estado actual, porque podría ser mucho mejor ...

De acuerdo, la calidad siempre ha sido un problema para todos los aspectos del desarrollo de Xamarin. Muchas veces me siento frustrado debido a las incompatibilidades entre los componentes, no funciona la compilación en VS o mi aplicación se bloquea después de una actualización a la nueva versión de Forms. Las cosas deberían funcionar. No debería verme obligado a reconstruir mi diseño por tercera vez porque algunos controles o diseños simplemente no funcionan bien juntos.

Veo un par de puntos relacionados

1. No sé cuántas personas trabajan en Formularios, pero a mí me parece que el equipo es demasiado pequeño para seguir el ritmo de crecimiento rápido de nuevos errores o relaciones públicas. Esto solo empeorará ya que tendrán que dividir la atención entre Forms y Maui. Realmente espero que el equipo reciba un impulso sustancial pronto.
2. Realmente ayudaría si Microsoft comenzara a usar Formularios en sus propias aplicaciones. Y no me refiero a simples aplicaciones de demostración o conferencias. Me refiero a aplicaciones reales como Teams o Outlook. Me alegraría si me equivoco en esto, pero no logré encontrar ninguna aplicación de MS Forms en las tiendas y, según alguna fuente como este tweet https://twitter.com/safaiyeh/status/1219294459298344961 , usan principalmente reaccionar nativo.

• esto realmente no envía una buena señal porque si MS no usa su propia tecnología (XF), ¿por qué deberíamos hacerlo?
• El uso de formularios internamente en aplicaciones complejas podría ser una capa adicional de pruebas y podría reducir la cantidad de problemas que llegan al lanzamiento público. Además, pudieron ver que trabajar con Formularios no es tan fácil como nos dicen.

1. Veo otro problema en el hecho de que MS constantemente intenta reinventar la rueda en una forma de XF Xaml en lugar de utilizar soluciones ya probadas y existentes como Win UI Xaml. Tienen que invertir tiempo en desarrollar funciones ya existentes y en corregir errores que se introducen debido a eso y luego hay menos tiempo para otras funciones y correcciones de errores.

Estoy de acuerdo con muchos de los temas que mencionaste. Microsoft definitivamente necesita crear una aplicación empresarial usando Xamarin Forms o iOS o Android. Una vez que tengan un ejemplo de aplicación empresarial que funcione, no podemos quejarnos de que crear aplicaciones profesionales sea frustrante.

Xamarin Forms es un excelente marco multiplataforma para aquellos que desean crear una aplicación una vez y trabajar en todas partes. Funciona muy bien si crea aplicaciones simples. Pero una vez que comienzas a crear una aplicación más profesional con más funciones como animaciones, pestañas segmentadas, virtualización de datos, diseños complejos, etc., te encuentras luchando cada vez más contra el marco para que una función funcione. Encuentro que las cosas simples que deberían funcionar no son obvias o requieren hacks para que funcionen.

Características como Xamarin Hot Reload aún son prematuras en su etapa de desarrollo. Por ejemplo, si hago un cambio de estilo en App.xaml o en un diccionario de recursos referenciado desde App.xaml, que es donde guardo mis estilos y recursos, Hot Reload estropeará el diseño de la aplicación en el simulador o provocará el aplicación se bloquee.

Encuentro que Visual Studio tiene muchos errores al desarrollar aplicaciones de Xamarin. Por ejemplo, si selecciono mi proyecto de Android como proyecto de inicio, prueba con él y luego cambia a mi proyecto de iOS como proyecto de inicio, mostrará todo tipo de errores falsos. Destruir las carpetas bin u obj no ayuda. Requiere que reinicie VS. En otro ejemplo, VS perderá aleatoriamente su conexión con mi Mac mientras depuro mi aplicación. Hará que mi VS se congele. Haré un berrinche, cuestionaré mi pasatiempo y mi vida como desarrollador móvil, y forzaré a matar a VS usando el Administrador de tareas. Además, encuentro que las versiones futuras de Visual Studio reintroducen errores que fueron corregidos en versiones anteriores. No conozco ninguna forma de instalar una versión anterior de VS después de que se lance la última versión y la instale. Puedo desinstalarlo e intentar reinstalarlo usando el instalador, pero siempre instalará la última versión. No es como un paquete NuGet donde puede instalar cualquier versión.

Por último, ¿por qué un control de pestaña segmentado ya no forma parte del kit de herramientas de Xamarin? Las pestañas segmentadas se utilizan en casi todas partes. No debería tener que usar el juego de herramientas Syncfusion u otro juego de herramientas para usar un control que es tan común.

Estoy nervioso por adoptar el uso de MAUI cuando aparece en cualquier aplicación profesional que desarrolle hasta que se resuelvan muchas de estas frustraciones de los desarrolladores con Xamarin y Visual Studio. Jugaré y experimentaré con él cuando salga. Pero tendré más confianza si Microsoft sale y crea una aplicación empresarial usando MAUI en lugar de hacer aplicaciones de demostración simples.

¿Alguien puede aclararnos sobre las hojas de ruta de Xamarin Forms y MAUI? ¿Se mantendrán en paralelo? ¿Hay una parada difícil para el soporte de Xamarin Forms y Microsoft nos va a poner MAUI en una futura actualización de Visual Studio?

Gracias

@SunnyMukherjee De las preguntas frecuentes,

¿Cuál es el futuro de Xamarin.Forms?

La próxima versión principal de Xamarin.Forms se publicará alrededor de septiembre de 2020 y continuará actualizándose mediante el lanzamiento de .NET MAUI con .NET 6. Después de eso, Xamarin.Forms continuará recibiendo servicio prioritario durante 12 meses.

Básicamente, Xamarin.Forms se eliminará después de la versión 5.

@SunnyMukherjee De las preguntas frecuentes,

¿Cuál es el futuro de Xamarin.Forms?

La próxima versión principal de Xamarin.Forms se publicará alrededor de septiembre de 2020 y continuará actualizándose mediante el lanzamiento de .NET MAUI con .NET 6. Después de eso, Xamarin.Forms continuará recibiendo servicio prioritario durante 12 meses.

Básicamente, Xamarin.Forms se eliminará después de la versión 5.

Para mediados de 2021. . . si Covid no me mata antes, Maui o Xamarin Forms harán el trabajo.

@SunnyMukherjee Escucho tu dolor. He estado usando Xamarin.Forms desde que salió por primera vez, y ha avanzado mucho desde allí. Recuerde que Microsoft no creó Xamarin.Forms, solo compraron Xamarin en 2018. Entonces MAUI es el proyecto de Microsoft para reescribirlo para que sea mejor y hacerlo funcionar sin problemas con todo el .net. Trabajar con Xamarin.Forms no es trivial porque lo que tiene que hacer no es trivial. Mucha gente dice que simplemente deberían hacer lo que Uno o Flutter han hecho y hacer los controles por sí mismos por completo, pero eso va en contra de lo que es Xamarin.Forms. Es un marco de desarrollo nativo, que expone los controles nativos de una manera común. Esto no es tarea fácil. También he tenido muchos problemas con Xamarin.Forms, pero en general el tiempo ahorrado al usarlo en lugar de escribir la misma aplicación en varios idiomas supera con creces los problemas. Además, la posibilidad de compartir el 90% del código con los proyectos centrales de ASP.Net hace que valga la pena.
Si bien es importante que Microsoft sepa lo que queremos en MAUI, pero tenemos que entender que no es una tarea pequeña para ellos, y tengo la esperanza de que MAUI sea un gran paso en la dirección correcta.
Mire este video de la compilación reciente de esa demostración MAUI y explica cómo encaja en las hojas de ruta y también lo que harán y apoyarán en Xamarin.Forms mientras tanto:
https://channel9.msdn.com/Events/Build/2020/BOD106?ocid=AID3012654&WT.mc_id=Build2020_pmmsocialblog

Al leer aquí, me pregunto qué puedo aprender aquí para mejorar la calidad de Xamarin.Forms. Me encantaría volver a la pregunta original de @ Happypig375 :

¿Alguna idea sobre cómo mejorar?

Uno de nuestros principales objetivos entre ahora y el envío de .NET MAUI es mejorar la base, el punto de partida. Por esta razón, estamos gastando gran parte de nuestros sprints actuales en problemas de CollectionView y proponemos pausar el desarrollador de características en Xamarin.Forms 5 para que tengamos desde septiembre de 2020 hasta noviembre de 2021 para cambiar más el enfoque a la resolución de problemas.

Todo esto es visible en nuestros tableros de proyectos de sprint.

En breve:

• Sea más rápido en la solicitud de extracción de la comunidad.

Cambié la base del árbol de solicitudes de extracción hace días. ¿Por qué tarda tanto la revisión?

WPF-Renderer, puntos de posibles errores:

• Medida / disposición de los controles
• El árbol infantil lógico / visual está roto
• Rendimiento

Hola @davidortinau , creo que una buena forma de abordar esto es dedicar públicamente a alguien a participar plenamente en:

• triaje de problemas de errores
• administrar, enviar y presionar para que se revisen y fusionen las relaciones públicas.

Él / ella seremos nuestro punto de contacto si algo va demasiado lento y él / ella puede explicar qué está pasando.
Además, si hay impedimentos no legales, sería fantástico si pudiéramos tener un canal de Twitch donde a su vez alguien corrija un error o revise un PR online. IHMO, esto podría tener un impacto tremendo en el interés y la colaboración de los desarrolladores externos.
Esto es válido para .NET MAUI y Xamarin Forms. Pero tal vez solo soy un soñador 😄

Realmente no me sorprende que Xamarin.Forms tenga muchos errores considerando la cantidad de plataformas en las que se está ejecutando y los cambios de las plataformas o por su propio desarrollo.

Sin embargo, lo que me sorprende es la cantidad de errores de regresión, cosas que funcionaron antes o se solucionaron antes y luego se rompieron con la próxima versión.
Para mí, esta es una clara señal de que no se han realizado suficientes pruebas. Un régimen de prueba más estricto puede llevar a que algunos cambios no estén en el próximo lanzamiento, pero detectarlos temprano es realmente necesario para evitar el estigma de un producto que no es confiable, para decirlo sin rodeos.

Más pruebas es algo que me gustaría ver como lección extraída de Xamarin.Forms para MAUI. Podría evitar muchos problemas reportados y recursos desperdiciados porque el código defectuoso tomó el camino más largo en lugar de ser abordado inmediatamente con el PR creado.

Cuando dije "características principales" y "errores críticos". Esto es lo que quiero decir con un tema como este . Esto es muy molesto ahora. He hecho un lanzamiento una semana sin saber realmente este problema. Me preguntaba por qué se redujo drásticamente la retención de aplicaciones. Imagine que tengo en su mayoría personas que no hablan inglés y un usuario español o alemán abre la aplicación y es en inglés debido a este error. Lo desinstalará de inmediato, aunque mi aplicación está traducida a ese idioma. Este error puede ocurrir, pero se informó hace un montaje. por qué no se solucionó. Incluso Appcenter y Azure Pipelines tienen ese error.

Para mejorar el marco. Me gustaría agregar:

Mejore la posibilidad de escribir su propio renderizador. Evite la palabra clave internal .

En lugar de simplemente publicar proyectos de muestra en GitHub, Microsoft puede crear una aplicación empresarial profesional como OneDrive o la aplicación Xbox con Xamarin Forms, iOS o Android y publicarla en la App Store para que la utilicen otras personas que no sean desarrolladores. Microsoft lo ha hecho antes al migrar Visual Studio de C ++ a C # y WPF (dado que el cliente es el desarrollador en ese caso). Eso le informará a Microsoft sobre nuestros puntos débiles y, si tienen éxito, le dará una tremenda confianza a la comunidad de desarrolladores de que todo es posible con Xamarin.

Me alegro de que haya una publicación sobre esto y me gustaría sopesar mi frustración. A menudo soy pasivo al publicar respuestas a problemas existentes, pero lo que me desencadena es este problema en relación con los BundleAssemblies ; Después de más de 2 meses de este problema de alto impacto, todavía no tengo una indicación clara de cuál es la solución, el estado o el camino a seguir de los miembros de Xamarin.

Dirijo el equipo Agile Scrum, y muy a menudo el KPI es la Velocidad (la cantidad de trabajo realizado). A veces, cuando tenemos un problema escalado a un cierto nivel acalorado, mi declaración final siempre será "... Me pregunto qué puedo aprender aquí para mejorar la calidad de" [nuestro producto]. No te ofendas (en realidad), pero eso es solo para tratar con condescendencia a mi jefe o nuestro cliente. Cuando digo eso durante ese tipo de contexto de discusión, solo significará que yo o el Dueño de mi Producto no estamos a la altura del trabajo o estamos en un estado de negación o peor aún, realmente no sabemos qué está pasando. (Felicitaciones a uno de nuestros interesados ​​que me da una palmada)

Lo que realmente me molesta son los errores de regresión y la falta de una respuesta / explicación concisa al problema. Todos los lanzamientos de XF tienden a romper algo; y rompe algo que es obvio: alineación incorrecta, imagen que no se muestra, truncamiento del texto que no funciona, etc. La mitad de nuestros casos de prueba son solo para verificar estas regresiones XF; es ridículo. Obviamente, hay algo mal con las pruebas internas de XF. Incluso cuando se reconoce un error que detiene el espectáculo, puede haber varios lanzamientos nuevos posteriores; ¿Qué sentido tienen esos nuevos lanzamientos cuando no podemos usarlos? ¿No deberían esos nuevos lanzamientos ir a tu Beta?

Habiendo dicho todo esto, nuestros accionistas y yo estamos muy cansados ​​de la "cultura tóxica" con XF. Es como cómo Windows 10 puede lanzar una actualización que elimina los archivos del usuario o el sistema del usuario de ladrillo (pero al menos su respuesta y revisión es rápida). Creo que nuestra frustración aquí no se trata de la falta de funciones en XF, sino de la calidad del lanzamiento. ¿En cuanto a cómo XF puede mejorar la calidad? Puede buscar en línea y obtener millones de resultados; y ni siquiera estoy seguro de por dónde empezar aquí sin ser arrogante para socavar la comprensión de Microsoft de "garantía de calidad". Estoy seguro de que Microsoft sabe cómo garantizar la calidad (he leído los documentos técnicos de Microsoft sobre esto). Todo se reduce a la persona a cargo; él / ella necesita la responsabilidad, la rendición de cuentas y el compromiso para mejorar (o implementar) el control de calidad.

Creo que lo más frustrante con respecto a XF es cuando el equipo simplemente ignora nuestra contribución (ya sea un nuevo relaciones públicas, un nuevo problema o incluso una simple pregunta o comentario).
Probablemente el equipo sea demasiado pequeño. Pero tener una persona dedicada a proporcionar respuestas en un tiempo razonable definitivamente ayudaría.

Un buen ejemplo es esta regresión con respecto a BundleAssemblies (ya se ha mencionado varias veces).
Otro buen ejemplo es este problema con CollectionView.

Otra preocupación para mí es que una aplicación XF se ve afectada por cambios en XF, por supuesto, pero también Mono, Visual Studio, Xamarin Framework, DotNet e incluso algunas bibliotecas de Microsoft.
Tengo la sensación de que esos equipos no se comunican bien internamente.
En mi opinión, que Microsoft use XF internamente para sus aplicaciones definitivamente ayudaría.

Una vez más, un buen ejemplo es esta regresión , cuya causa raíz está en realidad en Mono y AndroidX.
Pero también puedo mencionar este problema en las extensiones de dotnet que afectan a las aplicaciones de iOS, o incluso este problema en msal.
Y, por supuesto, este problema en Visual Studio , con respecto al enlace de origen.

La gente de aquí hizo un gran trabajo diciendo la mayor parte de lo que iba a decir en detalle, así que lo haré rápido.

Problemas técnicos

• Visual Studio se bloquea más de 3 veces por minuto cuando se trabaja con XF.
• Faltan muchos controles básicos, o requieren mucho para darles la forma que se supone que deben ser.
• Cuando dices XF, solo estás diciendo el marco de plataforma cruzada de peor rendimiento, y déjame ser claro para la gente que dice que XF aborda el Android / iOS nativo ... y así de difícil. ¡Solo mira! ¡por favor mira! ¡por el amor de Dios! en flutter, RN, NativeScript ... Todos tienen el mismo objetivo pero XF está muy por detrás
• La recarga en caliente funciona bien solo cuando creas un nuevo proyecto y haces el texto predeterminado en el lado izquierdo y eso es todo, ¡entonces tú solo!
• Todos en la comunidad de flutter, por ejemplo, en cada lanzamiento, digan: Oh, Dios mío, es tan genial lo que hicieron. Por otro lado, la comunicación XF es como: ¡Veamos qué rompieron o qué agregaron que solo el 10% de la comunicación necesita!
• Un viaje inicial usando XF es una serie de diablos, un ejemplo sería: recientemente tuve que hacer uno de los controles comunes en todas las aplicaciones en Playstore, que es solo un icono de pestaña inferior simple, el uso de shell con icono solo tiene un gran margen en la parte inferior, que se ven feos y como todos, creé un problema, solo para notar que un problema similar se abordó hace más de 6 meses ... Y no hay solución en el camino
• ¿Piensas en una aplicación okey? ¿Alguna aplicación? ¿Tiene una compra en la aplicación o algún tipo de servicio premium? Claro que lo hace. Entonces, comienzas a buscar un complemento para Google Pay y Apple Pay, ¿verdad? O incluso paypale, ¿verdad? Déjame decirte algo, ¡¡¡no lo hay !!! Cuando le preguntes al equipo oficial de XF, ¿sabes qué te responderán? Te envían un enlace a un complemento no oficial desactualizado creado por un hombre (que respeto) hace 2 años sin actualización, ¡WTF (lo siento)!

No técnico

• Oh, comome ooon, incluso la documentación oficial es muy pobre, abordan características a nivel de aplicación de tareas pendientes y tutoriales prácticos
• Odiaba XF incluso antes de usarlo, ¿sabes por qué? Todo el mundo dice que incluso la EM no usa, así que ¿por qué la F la usarías?
• ¡Una respuesta muy lenta para los problemas y las relaciones públicas que la comunidad hace en su propio tiempo y con sus propios gastos para ayudar al equipo de XF!

Soluciones

• El equipo de XF es muy, muy pequeño. ¿Cómo puede una empresa enorme si Microsoft no contrata a suficientes personas para mejorar su propio producto? ¡Hay talentos en todo el mundo que aman a Microsoft tanto como yo!
• El XF debería abordar problemas de alto nivel antes de su lanzamiento, solo muestra cuán inmaduro es el equipo, como un barco a quién le importa ...
• Microsoft más y está obligado a utilizar XF para sus productos. Si no es solo una forma de decir que XF es bueno, pero no, no me gusta, puaj
• ¡Haz una documentación muy rica! Un médico que es el primero en acudir en la mayoría de las situaciones, ¡contrata a más personas! es tan fácil como eso, hay muchos desarrolladores experimentados que blogs pueden trabajar con ellos
• XF no es tan conocido como Flutter. Haz asociaciones con los grandes influencers de codificación en youtube, incluso una simple mención ayuda a XF.
• También está bien mirar otros productos y ver qué le gusta al desarrollador de ellos y hacer tu propia versión. Flutter, por ejemplo.
• ¡No tengas miedo de preguntarle a la comunidad qué es lo que quieren, no vivas debajo de una roca y hagas lo que nadie usará!

Lo siento mucho por mi comportamiento agresivo y mi mal inglés, ¡me gusta mucho XF!
Maui es un nuevo punto de partida, conviértalo en la nueva revolución, todos esperan ser algo grandioso, así que no nos decepciones, tenemos grandes esperanzas.

@ Amine-Smahi Comuníquese por correo electrónico con más información sobre el comportamiento que conduce a fallas ([email protected]).

Estoy completamente de acuerdo en que la corrección de errores y el proceso de prueba de nuevas funciones es terrible.

Por ejemplo:
https://github.com/xamarin/Xamarin.Forms/issues/3335 - deja de usar ListView.RecycleElement
https://github.com/xamarin/Xamarin.Forms/issues/4168 - deja de usar CompressedLayout

Cuando agrega nuevas funciones que mejoran el rendimiento, ¡eso es genial! Pero cuando estas funciones no se pueden utilizar, es muy decepcionante.

Y algunos de los problemas que afectan a mis aplicaciones y no se solucionan durante mucho tiempo:
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

El equipo debe asumir la responsabilidad de las funciones que implementan. Por ejemplo, @StephaneDelcroix implementó https://github.com/xamarin/Xamarin.Forms/pull/1136. Creo que él es la persona a la que se debe asignar https://github.com/xamarin/Xamarin.Forms/issues/4168 y corregir errores relacionados con CompressedLayout.

Acerca de la documentación: Personalmente, creo que es en su mayoría bien, a excepción de las notas de la versión, que son totalmente f * d arriba;) (siempre tarde o incompleto)
Nuevamente, no estoy hablando específicamente de XF, sino más generalmente de todo el framework xamarin (xamarin.android, xamarin.ios, visual studio, mono, componentes ...).

Aquí hay un ejemplo: notas de la versión de xamarin ios

@melimion

Cuando agrega nuevas funciones que mejoran el rendimiento, ¡eso es genial! Pero cuando estas funciones no se pueden utilizar, es muy decepcionante.

Esto es absolutamente cierto.
Ha agregado un CollectionView. El resultado es un montón de errores en Android, en iOS generalmente no se puede usar (excepción eliminada, excepción de inconsistencia NS, etc. Y esto es si hace todo de acuerdo con las guías oficiales (!).
Agregó CarouselView: los errores son los mismos.
Tenemos que usar un Listview desactualizado pero más estable.

Ahora, cuando veo el título "agregamos", inmediatamente me desplazo más lejos.
Y también tienes otros elementos, por ejemplo
Swipeview, Expander, que también tienen muchos errores.
Y luego está, como escribió la persona anteriormente, mono, visual studio con sus propios errores.

Cancele las nuevas funciones en 4.7-4.8, preste atención a las correcciones de errores.
El desarrollo en Xamarin es como encontrar soluciones temporales, soluciones temporales.
Me disculpo por mi pobre ingles

Ayer lo he comprobado. Hay más de 200 problemas marcados con alto impacto. No tiene sentido lanzar nuevas funciones, cuando los errores críticos aún no se han resuelto. Estoy de acuerdo con la sugerencia anterior. Detenga las funciones nuevas. Tómese su tiempo para solucionar y reducir la cantidad de problemas. Estoy atascado en 4.4, por ejemplo, debido a un problema. Imagínese mucha más gente en esta situación. La estabilidad y el rendimiento son lo primero, si no hay mano de obra para tener innovación y mantenimiento en mi humilde opinión.

Me pregunto si podría haber algún tipo de encuesta entre los desarrolladores de XF para ver si preferiríamos que se hiciera un esfuerzo de ingeniería para eliminar los errores existentes o agregar las características planeadas para 4.7 y posteriores. Quiero decir que las nuevas características agregarán más errores nuevos, lo que provocará más reelaboración y más demoras ... a veces se requiere una buena congelación de características a la antigua.

Para mí, personalmente, me gustaría ver el mayor esfuerzo en MAUI, que suena como un restablecimiento sensato de la arquitectura XF, con el segundo mayor esfuerzo en eliminar errores de alto impacto. Agregar nuevas funciones ni siquiera estaría en mi lista; prefiero agregarlas cuando tengamos una plataforma mejor para agregarlas.

@freever ¡ Estoy totalmente de acuerdo!
Esto no solo hará más felices a los desarrolladores actuales de Xamarin, sino que también resolverá esos errores para MAUI.

No sé si estos errores se llevarán a cabo para solucionarlos aquí en MAUI, o se solucionarán en Xamarin.Forms.

Siento que @davidortinau cubrió el espíritu de este número aquí.

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

Actualicé la descripción con su comentario.

Realmente quiero resaltar esta parte de lo que dijo nuevamente para todos.

Estamos gastando gran parte de nuestros sprints actuales en problemas de CollectionView y proponemos pausar el desarrollador de características en Xamarin.Forms 5 para que tengamos desde septiembre de 2020 hasta noviembre de 2021 para cambiar más el enfoque a la resolución de problemas.

PureWeen cerró esto hace 10 horas

Decenas de desarrolladores de xamarin han expresado su opinión en este ticket, y no tengo la sensación de que hayan sido escuchados.
Lamentablemente, acabas de demostrar mi punto.

@PureWeen Este problema cubre mucho más que una simple cantidad de errores. Incluso se enumeran en forma de puntos.

@ tranb3r

Creo que lo más frustrante con respecto a XF es cuando el equipo simplemente ignora nuestra contribución (ya sea un nuevo relaciones públicas, un nuevo problema o incluso una simple pregunta o comentario).

¿Cómo te queda corto el comentario de

@ Happypig375

@pauldipietro se acercó a la persona que publicó ese problema para que pueda comenzar a abordar esos problemas de manera más directa con ellos.

El espíritu de este problema es que XF tiene demasiados errores e ignora a la comunidad. Por lo tanto, estamos ralentizando el nuevo desarrollo para centrarnos más en los errores existentes y las relaciones públicas abiertas.

Si hay otros problemas fuera de los errores abiertos, abramos los problemas para ellos. Pero este problema se trata de que hay demasiados errores abiertos y tenemos un plan para solucionarlo.

Con MAUI, deberíamos tener un proceso de corrección de errores lo más rápido posible. ¿Alguna idea sobre cómo mejorar?

Estamos eliminando un montón de aspectos heredados de Form con .NET Maui y gastaremos este año antes de centrarnos en los errores y las relaciones públicas abiertas para que podamos ser más productivos con .NET Maui

Este es nuestro tablero de proyecto

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

Puedes ver lo que estamos agregando a cada sprint.
https://github.com/xamarin/Xamarin.Forms/projects/70

Aquí está nuestra hoja de ruta
https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap
Intentamos ser lo más transparentes posible con lo que estamos trabajando.

Si los problemas en esos repositorios reciben ping o tienen un enfoque alto, intentamos hacerlos aparecer en la parte superior, pero a veces esos algoritmos no son perfectos.

@ Amine-Smahi aquí está el tablero del proyecto para shell y lo que vemos como bloqueadores
https://github.com/xamarin/Xamarin.Forms/projects/54

¿Puede indicarme el problema al que se refiere para que pueda echarle un vistazo?

@PureWeen

¿Cómo te queda corto el comentario de

Como se mencionó anteriormente, este problema cubre mucho más que el número de errores en XF.

Si hay otros problemas fuera de los errores abiertos, abramos los problemas para ellos. Pero este problema se trata de que hay demasiados errores abiertos y tenemos un plan para solucionarlo.

¡¡¡Ya hay demasiados problemas abiertos !!! ¿Cuál es el punto de abrir nuevos si simplemente los ignora ...

Por ejemplo, uno de los puntos importantes mencionados anteriormente es que los equipos de Microsoft deben usar xamarin al desarrollar aplicaciones.
¿Escuchas esta retroalimentación? ¿Qué debemos hacer para convencerte de que es una buena idea? ¿Se supone que debemos abrir un problema por eso?

Como se mencionó anteriormente, este problema cubre mucho más que el número de errores en XF.

Creemos diferentes problemas para esos. Abordar varias cosas en un solo problema no será productivo.

¿Qué otros comentarios aquí que no tienen nada que ver con problemas abiertos de errores / prs / fragilidad en torno a XF le gustaría tener claridad?

Por ejemplo, uno de los puntos importantes mencionados anteriormente es que los equipos de Microsoft deben usar xamarin al desarrollar aplicaciones.
¿Escuchas esta retroalimentación? ¿Qué debemos hacer para convencerte de que es una buena idea? ¿Se supone que debemos abrir un problema por eso?

Sí, intentamos convencer literalmente a todos para que usen Xamarin

Hablamos mucho con los equipos internos sobre las opciones de aplicaciones y es un debate continuo. Muchas de estas discusiones internas también guiarán la dirección de .NET Maui.

No estoy seguro de qué más puedo comentar sobre esto. No hay muchas acciones aquí que pueda hacer para ayudarlo específicamente como usuario.

@PureWeen El espíritu de este problema es que XF tiene demasiados errores e ignora a la comunidad. Por lo tanto, estamos ralentizando el nuevo desarrollo para centrarnos más en los errores existentes y las relaciones públicas abiertas.

Por lo tanto, esperamos una tasa de corrección de errores ligeramente más rápida durante un tiempo. Eso es bueno, pero no aborda completamente este problema. Llevar XF de calidad beta a estable es una tarea muy grande y ninguna solución rápida o estrategia única lo logrará. Se necesitarán importantes cambios organizativos, filosóficos y arquitectónicos. Yo sugeriría:

1. Simplifique el repositorio para que sea más fácil contribuir y revisar las contribuciones. La nueva arquitectura de renderizador podría ayudar si desplaza XAML del núcleo y brinda un enfoque más seguro para los renderizadores.
2. Priorice las correcciones de errores y limpie el código sobre las funciones. Dado que la cultura de Xamarin es agregar nuevas características sin tener en cuenta los errores, la mejor manera es prohibir completamente las nuevas características hasta que se alcance un umbral de calidad para las características existentes.
3. Permitir cambios importantes que corrigen errores y limpian el código.
4. Haga un uso completo de .Net para reducir errores. Mantenga las cosas dentro del sistema de tipos siempre que sea posible y adopte C # 8 NRT.
5. Arregle los controles más básicos primero , luego los controles restantes.
6. Elimine los sistemas operativos de destino antiguos y los editores antiguos para limpiar el repositorio, optimizar las pruebas y liberar recursos para corregir errores.
7. Informar sobre una métrica de errores públicamente. Esto ayudará a que la organización se concentre en los errores. Coloque el progreso en los errores como la primera sección de cualquier blog sobre una actualización.
8. Elimine funciones para reducir el tamaño del repositorio y hacerlo más fácil de mantener.

Nuestra experiencia: solo usamos vistas XF básicas porque no confiamos en que se pueda usar nada más. Etiqueta, entrada, botón, selector, conmutador, selector de fecha, control deslizante, diseño de pila, vista de desplazamiento, vista de contenido, cuadrícula, página de contenido. Pero incluso entonces, los errores surgen y permanecen durante meses. Es tan difícil obtener correcciones en XF que simplemente copiamos y pegamos renderizadores en nuestro código.

Simplifique el repositorio para que sea más fácil contribuir y revisar las contribuciones. La nueva arquitectura de renderizador podría ayudar si desplaza XAML del núcleo y brinda un enfoque más seguro para los renderizadores.

Ese es nuestro plan. He creado un problema de marcador de posición aquí que puede seguir u ofrecer sus sugerencias https://github.com/dotnet/maui/issues/147

Priorice las correcciones de errores y limpie el código sobre las funciones. Dado que la cultura de Xamarin es agregar nuevas características sin tener en cuenta los errores, la mejor manera es prohibir completamente las nuevas características hasta que se alcance un umbral de calidad para las características existentes.

Este es principalmente nuestro plan.

Permitir cambios importantes que corrigen errores y limpian el código.
Haga un uso completo de .Net para reducir errores. Mantenga las cosas dentro del sistema de tipos siempre que sea posible y adopte C # 8 NRT.

Este es poco a poco nuestro plan. Pero es importante comprender el alcance total de los usuarios que utilizan nuestros productos. Por ejemplo, una vez que rompimos la compatibilidad con vs2017, apareció este problema que recibió una tonelada de comentarios de los usuarios.
https://github.com/xamarin/Xamarin.Forms/issues/7602

Así que no podemos simplemente dar el salto. Me encantaría dar ese salto al cien por cien, pero no podemos simplemente quebrar a la gente.

Pero siempre tomamos medidas para estar preparados para este salto. Por ejemplo, el PR aquí
https://github.com/xamarin/Xamarin.Forms/pull/10937

Me permitirá ejecutar un proceso de CI interno para probarlo con C # 8 y otras funciones beta, de modo que una vez que podamos dar el salto, será un salto fácil de dar.

Arregle los controles más básicos primero, luego los controles restantes.
Elimine los sistemas operativos de destino antiguos y los editores antiguos para limpiar el repositorio, optimizar las pruebas y liberar recursos para corregir errores.

Ese es nuestro plan como mencioné anteriormente.

Informar sobre una métrica de errores públicamente. Esto ayudará a que la organización se concentre en los errores. Coloque el progreso en los errores como la primera sección de cualquier blog sobre una actualización.

Mirando esto. @samhouts ejecuta muchos de estos informes para nosotros en cada sprint, por lo que tenemos una perspectiva de todo, pero analizaremos la superficie de esto mejor para la comunidad.

Elimine funciones para reducir el tamaño del repositorio y hacerlo más fácil de mantener.

Este es nuestro plan con .net MAUI. Antes de lanzar nuestro plan .NET MAUI, preparamos listas de áreas que podemos reducir para que sean más efectivos. Una gran parte de esto será el trabajo del renderizador.

Hola, además de los problemas mencionados, hay muchos errores relacionados con los idiomas de derecha a izquierda. Parece que estos errores son de menor importancia desde el punto de vista del equipo de Xamarin Forms (probablemente debido al menor uso de idiomas de derecha a izquierda que el inglés u otros idiomas de izquierda a derecha). Idiomas correctos), pero la falta de soporte completo para culturas de derecha a izquierda, es desalentador y decepcionante y, de hecho, impide que los desarrolladores usen XF en aplicaciones internacionales / multilingües / de derecha a izquierda.
Gracias.

Próximo número de dos meses: https://github.com/xamarin/Xamarin.Forms/issues/11166
Error creado el 22 de junio.
PR abrió el 25 de junio.
Estado del error 17 de agosto: aún no se ha fusionado. ¿Por qué? ; (

@PawKanarek bienvenido a Xamarin. por lo general, solo combinan arreglos o Prs realizados por el equipo. por eso es desalentador contribuir en Xamarin. Creo que redujeron la capacidad del equipo. solo 2-3 personas trabajando activamente en el proyecto. si necesita una solución rápida, cree sus propios paquetes xamarin nuget.

@EmilAlipiev Pero esta vez el PR (para # 11166) fue abierto por un miembro del equipo de Xamarin y aún no se ha fusionado xD

Si echas un vistazo a nuestras notas de lanzamiento y a los conocimientos de GitHub, fusionamos toneladas de relaciones públicas de la comunidad. De hecho, veo su nombre en la última lista , @EmilAlipiev :)

Puede ver que durante el último mes, 18 personas diferentes han abierto 40 nuevas solicitudes de extracción . Las solicitudes de extracción deben probarse y revisarse por completo, y con la cantidad que recibimos, tenemos que priorizar los problemas de bloqueo y las regresiones importantes sin soluciones alternativas.

Sé que no siempre somos perfectos, pero trabajamos para mejorar cada día. Gracias por su paciencia y por seguir con nosotros. ¡Podemos hacerlo juntos!

@ hamiddd1980 Le alegrará saber que hemos estado trabajando bastante en RTL durante los últimos meses. ¡Espero que mejore tu experiencia!

@samhouts Solo recuerda que no eres un producto final de Xamarin. No solo necesitamos paciencia, sino también muchos recursos humanos y dinero. Cualquier error abierto y verificado en github debe solucionarse lo antes posible porque crea un efecto de bola de nieve en forma de deuda técnica, enojo y tensiones innecesarias con nuestros clientes.

Corrija más errores, no agregue más funciones. Estabilidad sobre la funcionalidad. Todavía tiene 1,590 errores verificados https://github.com/xamarin/Xamarin.Forms/issues?q=is%3Aopen+is%3Aissue+-label%3As%2Funverified+label%3A%22t%2Fbug+%3Abug%3A% 22

@samhouts gracias por tu respuesta. 1-2 fusiones por día es extremadamente menor. Trabajo en otra herramienta multiplataforma y tienen 15 fusiones por día 455 fusiones el mes pasado. Sin embargo, todavía amo más a Xamarin como herramienta y estoy dispuesto a contribuir siempre, pero mi fusión tomó más de 2 meses y tuve que crear esta fusión 3 veces con rebased de diferentes ramas.
Además de eso, hay un problema de priorización de su lado. La gente está buscando desesperadamente soluciones para herramientas básicas como errores como Device.Idiom .. o CollectionView, etc.
Hoy ha habido un gran progreso, de hecho, 8 fusiones totales hasta ahora. Pero para ser honesto, debajo de las fusiones, menos gente está interesada en la vista de deslizamiento, pinceles de degradado o temas, etc. cuando hay RP tan críticos en cola durante meses. Esta es la mayor frustración que creo

Cualquier error abierto y verificado en github debe corregirse lo antes posible

Obviamente, esto es poco realista; incluso si Microsoft aumentó drásticamente el tamaño del equipo de Xamarin.Forms.
Trabaje de manera más inteligente, no más difícil, dicen (en este caso, esto debería significar requerir que los RP incluyan pruebas de regresión para asegurarse de que los errores no reaparezcan; sin embargo, como con cualquier cosa, esto también es una compensación, porque las revisiones de Los RP se harán más largos y más difíciles).

Corrija más errores, no agregue más funciones

Esta es una opinión que yo también comparto. Sin embargo, estrictamente hablando, el plan de transición MAUI <> Xamarin.Forms ya cubre esto: Xamarin.Forms pasará solo al modo de corrección de errores, mientras que las nuevas características solo llegarán a Maui.

(en este caso, esto debería significar requerir que los RP incluyan pruebas de regresión para asegurarse de que los errores no reaparezcan; sin embargo, como con cualquier cosa, esto también es una compensación, porque las revisiones de los RP contribuidos serán más largas y más difíciles).

Absolutamente. Esta es una compensación con la que también hemos estado luchando. Tenemos miles (!) De pruebas automatizadas y las ejecutamos en varios dispositivos. El problema es que se necesitan horas (actualmente alrededor de 4 horas por ejecución por dispositivo) para que se completen y, a veces, desafortunadamente, son un poco inestables por varias razones. Por ejemplo, ayer hice un ping a un colaborador sobre una prueba que pensé que estaba fallando legítimamente, solo para darme cuenta de que en realidad estaba fallando porque Chrome nos pedía que aceptemos los nuevos términos de servicio. 🤦

Esto genera muchos retrasos y significa que los RP a veces pueden tardar días en aprobar las pruebas. Eso depende de nosotros y es un problema que debemos resolver.

Afortunadamente, estamos trabajando en este problema. Estamos desarrollando un nuevo método para probar los renderizadores de la plataforma más parecido a las pruebas unitarias que a la automatización de la interfaz de usuario, que es mucho más confiable y rápida.

En cuanto a agregar nuevas funciones frente a corregir errores ... como dice @knocte , el plan de transición está diseñado con esto en mente. Nuestro objetivo es que .NET MAUI sea ágil, rápido y confiable. Como parte de esto, estamos evaluando qué características pertenecen realmente al proyecto principal y qué características son más adecuadas para el nuevo kit de herramientas de la comunidad, que todavía cuenta con el respaldo de Microsoft, pero en gran parte es compatible con la comunidad.

Tenga en cuenta que siempre lo tenemos en cuenta a usted y a sus clientes cuando hacemos cualquier cambio, y estamos escuchando sus comentarios.