Compatibilidad de versiones anteriores de Symfony

Symfony tiene especial cuidado a la hora de lanzar versiones nuevas y tiene una política estricta en la compatibilidad de versiones anteriores

Contenido modificable

Si ves errores o quieres modificar/añadir contenidos, puedes crear un pull request. Gracias

Asegurarse de que las actualizaciones se pueden realizar bien es una de las prioridades de SensioLabs. Prometen backwards compatibility (BC) para todos los lanzamientos de versiones minor. Este estrategia es del tipo Semantic Versioning, y significa que sólo las versiones mayor (2.0, 3.0, etc) pueden romper con la compatibilidad de versiones. Las versiones minor (como 2.5, 2.6, etc) pueden introducir nuevas características, pero deben hacerlo sin romper el API existente.

Sin embargo, la compatibilidad entre versiones es aplicable de formas muy diferentes. De hecho casi cada cambio que se hace en el framework puede potencialmente romper una aplicación. Si añaden un método a una clase, esto romperá una aplicación que extendía esta clase y añadía el mismo método, pero con diferente nombre.

Además, no todos los BC breaks tienen el mismo impacto en el código de una aplicación. Mientras algunos BC breaks requieren que hagas cambios significativos a tus clases o arquitectura, otros se solucionan de forma tan fácil como cambiando el nombre del método.

Por ello se ha creado la guía de compatibilidad de versiones. La sección "Usando el código de Symfony" muestra cómo puedes asegurar que tu aplicación no se romperá por completo cuando se actualice a una nueva versión de una misma versión mayor.

La segunda sección, "Modificando el código de Symfony" va dirigida a los contribuyentes de Symfony. Esta sección detalla reglas que cada contribuyente tiene que seguir para asegurar actualizaciones cómodas a los usuarios.

Usando el código de Symfony

Las siguientes pautas ayudan a asegurar actualizaciones seguras en las futuras versiones minor de Symfony.

Interfaces

Todas las interfaces de Symfony pueden usarse en type hints. Puedes también llamar a cualquiera de los métodos que declaran. Desde Symfony garantizan que no romperán código que tiene estas reglas.

La excepción a esta norma es que las interfaces etiquetadas con @Interval no deberían usarse o implementarse.

La siguiente tabla explica los casos que respetan la compatibilidad de versiones:

Uso Compatibilidad de versiones
Si tu... Desde Symfony garantizan BC
Haces type hint en la interface
Llamas a un método
Si implementas una interface y... Desde Symfony garantizan BC
Implementas un método
Añades un argumento a un método implementado
Añades un valor por defecto a un argumento

Clases

Todas las clases de Symfony pueden instanciarse y pueden ser accedidas a través de sus métodos y propiedades públicos.

Las clases, propiedades y métodos con la etiqueta @internal así como las clases localizadas en los namespaces *\Tests\ son una excepción a esta norma. Están construidas para uso interno sólamente y no deben ser accedidas desde tu propio código.

La siguiente tabla explica los casos que respetan la compatibilidad de versiones:

Uso Compatibilidad de versiones
Si tu... Desde Symfony garantizan...
Haces type hint en la clase
Creas una nueva instancia
Extiendes la clase
Accedes a una propiedad pública
Llamas a un método público
Si extiendes la clase y... Desde Symfony garantizan...
Accedes a una propiedad protected
Llamas a un método protected
Sobreescribes una propiedad public
Sobreescribes una propiedad protected
Sobreescribes un método public
Sobreescribes un método protected
Añades una nueva propiedad No
Añades un nuevo método No
Añades un argumento a un método sobreescrito
Añades un valor por defecto a un argumento
Llamas a un método private con Reflection No
Accedes a una propiedad private con Reflection No

Modificando el código de Symfony

Si quieres ayudas a mejorar Symfony, es necesario respetar las normas de este enlace para garantizar las actualizaciones seguras.