Política de compatibilidad de Flutter

El equipo de Flutter intenta equilibrar la necesidad de estabilidad de la API con la necesidad de seguir evolucionando las APIs para corregir errores, mejorar la ergonomía de la API y proporcionar nuevas características de manera coherente.

Con este fin, hemos creado un registro de pruebas donde puedes proporcionar pruebas unitarias para tus propias aplicaciones o librerías que ejecutamos en cada cambio para ayudarnos a rastrear cambios que romperían las aplicaciones existentes. Nuestro compromiso es que no realizaremos ningún cambio que rompa estas pruebas sin trabajar con los desarrolladores de esas pruebas para (a) determinar si el cambio es lo suficientemente valioso, y (b) proporcionar soluciones para el código de modo que las pruebas sigan pasando.

Si deseas proporcionar pruebas como parte de este programa, por favor envía un PR al repositorio flutter/tests. El archivo README en ese repositorio describe el proceso en detalle.

Si realizamos un cambio disruptivo (breaking change) (definido como un cambio que hace que uno o más de estos exámenes presentados requieran cambios), anunciaremos el cambio en nuestra lista de correo flutter-announce así como en nuestras notas de lanzamiento.

Proporcionamos una lista de guías para migrar código afectado por cambios disruptivos.

En ocasiones, depreciaremos ciertas APIs en lugar de eliminarlas por completo de la noche a la mañana. Esto es independiente de nuestra política de compatibilidad que se basa exclusivamente en si fallan las pruebas enviadas, como se describió anteriormente.

El equipo de Flutter no elimina las APIs depreciadas de forma programada. Si el equipo elimina una API depreciada, sigue los mismos procedimientos que para los cambios disruptivos.

El propio lenguaje Dart tiene una política de cambios disruptivos independiente, con anuncios en Dart announce.

En general, el equipo de Flutter no tiene actualmente ningún compromiso con respecto a los cambios disruptivos para otras dependencias. Por ejemplo, es posible que una nueva versión de Flutter que use una nueva versión de Skia (el motor de gráficos utilizado por algunas plataformas en Flutter) o Harfbuzz (el motor de modelado de fuentes utilizado por Flutter) tenga cambios que afecten a las pruebas aportadas. Dichos cambios no estarían necesariamente acompañados de una guía de migración.