Las nuevas funcionalidades experimentales de Symfony

Cuando un proyecto madura y crece tanto como Symfony, es necesario documentar y formalizar cómo es su desarrollo para que los usuarios puedan seguir utilizándolo con confianza. La parte más importante de ese proceso es nuestra Política de Retrocompatibilidad ("Backwards Compatibility Promise" en inglés) que asegura que puedas actualizar entre versiones menores de Symfony (por ejemplo, de 2.7.x a 2.8.x o de 3.1.x a 3.2.x) sin que se rompa tu aplicación.

Sin embargo, a veces queremos añadir funcionalidades que no estamos muy seguros de cómo implementarlas. Aplicar la misma política de retrocompatibilidad en estos casos no es una buena idea, ya que nos obligaría a mantener para siempre la API de esa primera implementación, sea buena o mala.

Cuando se añade una nueva funcionalidad a un framework, lo mejor es recibir comentarios de gente que la ha usado en aplicaciones reales para resolver problemas reales. De esta forma podemos ajustar la API a esas necesidades reales. Pero claro, para que la gente pueda probar una funcionalidad, primero hay que añadirla al framework, y entonces es cuando deberíamos aplicar nuestra política de retrocompatibilidad.

Un buen ejemplo de esta idea es el componente LDAP. Cuando lo añadimos en Symfony 2.8, decidimos declararlo como "experimental" durante toda esa versión de Symfony (cualquier versión 2.8.x). Con el tiempo hemos visto que hacer esto fue una buena idea, ya que, gracias a los comentarios de los usuarios que lo habían probado, hicimos cambios en la API para la siguiente versión (Symfony 3.0). Este componente ya no es experimental y su API (corregida gracias a la comunidad) ahora sí que está cubierta por nuestra política de retrocompatibilidad.

Después de algunas discusiones internas sobre este asunto, hemos decidido empezar a declarar algunas nuevas funcionalidades como experimentales. Esto significa que su API podría cambiar ligeramente en la siguiente versión de Symfony. Por supuesto usaremos esta opción de forma esporádica y solo cuando la nueva funcionalidad sea muy compleja o tengamos dudas sobre su API.

Otro caso en el que la usaremos será cuando no estemos seguros sobre si deberíamos añadir alguna funcionalidad o no, como por ejemplo el "getter injection" en el que estamos trabajando últimamente.

Para evitar confusiones, todas las funcionalidades experimentales lo indicarán claramente en la documentación y todas las clases PHP tendrán la etiqueta @experimental.

En resumen, mantenemos la política de retrocompatibilidad para la mayoría del framework, pero puntualmente nos la saltaremos para algunas funcionalidades, de manera que podamos perfeccionar su código sin restricciones.

Fuente: Experimental Features

• © 2024 - symfony.es
• Contacto
• Privacidad
• Condiciones
• v7

6.510 días online

Symfony es el mejor framework PHP para crear aplicaciones web.