Cuando el marco cambia de versión

Qué suele romperse

La cuarta fila es la que decide el calendario: no puedes migrar hasta que los plugins que usas lo hayan hecho, y ahí el nivel 68.2 se cobra — un plugin abandonado bloquea tu migración.

Migrar por partes

Y una recomendación de proceso: migrar en una rama, con la aplicación funcionando en la versión anterior mientras tanto — porque una migración a medias en la rama principal bloquea todo lo demás.

Cuándo actualizar

Tres momentos razonables, y uno malo:

• Cuando aparece una versión de correcciones de la que ya usas: casi siempre, y es barato.
• Cuando la versión nueva trae algo que necesitas.
• O cuando tus plugins ya han migrado y el ecosistema se ha estabilizado — que para un cambio de versión mayor suele ser unos meses después de salir.
• Y el momento malo: nunca, que es la opción por omisión si nadie decide.

Por qué quedarse atrás es caro

Y el razonamiento que merece tener claro:

• Las migraciones se acumulan. Saltarse dos versiones mayores no cuesta el doble: cuesta más, porque los cambios interactúan.
• Los plugins dejan de dar soporte a versiones antiguas del marco, y entonces tampoco puedes actualizarlos.
• Las correcciones de seguridad solo llegan a las versiones mantenidas.
• Y el motor y las plataformas cambian: una versión antigua del marco puede dejar de compilar o de funcionar en sistemas nuevos.

La cuarta es la que fuerza la mano al final, y suele llegar en un mal momento — cuando hay que publicar y de pronto no compila en la versión nueva del sistema operativo.