Angular publicará una sola versión grande al año desde Angular 23, prevista para junio de 2027. El cambio reduce la frecuencia de migraciones, amplía el soporte a 24 meses y busca mantener APIs más estables, también para flujos de trabajo con agentes de IA. Pero una "major" menos no elimina el trabajo: las actualizaciones y las deprecaciones siguen importando. Te contamos todos los detalles y porqué se ha tomado esta decisión.
Desde 2017 con la salida de Angular 4, este framework de Front-End nos tenía acostumbrados a sacar nuevas versiones grandes o "major" dos veces al año: alrededor de mayo y de noviembre. Ahora, con Angular 22, han cambiado esta regla y solo se publicará una versión major cada doce meses, siempre en el mes de junio. O sea, la siguiente será Angular 23, en junio de 2027.
Para quien mantiene aplicaciones Angular, sobre todo si tienen cierto tamaño, la noticia parece muy buena. Una major suele traer la necesidad de hacer migraciones, cambios en dependencias y una ronda de pruebas que nunca es tan automática como promete el comando ng update. Para otros, sin embargo, parece que esto va a ralentizar el ritmo de innovación de la plataforma y además hará las actualizaciones más grandes y por lo tanto más difíciles.
Yo creo que en el medio está la virtud y que no será ni una cosa ni la otra. Angular no va a congelarse durante un año, ni tampoco desaparecen los compromisos de actualización y las novedades. Vamos a ver cómo se planea gestionar este nuevo mundo...
El cambio del ciclo de actualización de Angular
La documentación ya recoge el nuevo calendario: entre una major y la siguiente habrá de cuatro a seis versiones minor, además de parches y versiones previas frecuentes. La actual versión, Angular 22, va a sacar versiones menores hasta, aproximadamente, marzo de 2027, y Angular 23 llegará en junio.
Estas actualizaciones minor mantienen la compatibilidad hacia atrás y de todas formas eran ya el canal normal para nuevas funcionalidades, incluidas las APIs en developer preview o experimentales.
Las majors, como marca el versionado semántico (Semver), se reservan para los cambios incompatibles: retiradas de APIs obsoletas y actualizaciones de dependencias que exigen tocar el proyecto. Es decir, llegarán menos sobresaltos de ese tipo, no menos trabajo en el framework.
OJO: también cambia el soporte: cada major tendrá 12 meses de soporte activo y otros 12 de LTS. En total, 24 meses, frente a los 18 de la política anterior. Esto es algo muy positivo también.
Lo que mejora con versiones de Angular una vez al año
Para equipos con aplicaciones grandes, una sola ventana anual de migración es más fácil de colocar en el calendario. Da tiempo para validar bibliotecas propias, esperar a que el ecosistema actualice sus dependencias y evita tener que encadenar una migración con la siguiente, casi sin respirar, que es lo que pasaba hasta ahora.
También encaja mejor con la política de obsolescencia de características (por ejemplo HttpModule desaparecidos en Angular 8, o los entryComponents eliminados en Angular 16, por poner dos ejemplos de esto).
Con este cambio, una API marcada como obsoleta seguirá disponible, como mínimo, hasta la próxima major, lo que equivale a alrededor de un año. Da un margen más razonable para, dentro de un ciclo normal de mantenimiento, resolver problemas de código que se va a quedar obsoleto.
Ahora, actualizar Angular deja de competir dos veces al año por el mismo hueco que reservas para renovar Node.js, TypeScript, Java, navegadores, CI y las miles de cosas que tenemos que usar en las empresas.
Lo que no es tan bueno con menos versiones principales de Angular
Pero claro, aunque solo haya una migración "gorda" al año, si Angular concentra más cambios incompatibles en cada major, la actualización puede ser más larga y complicada. Es evidente.
El equipo afirma que seguirá minimizando esos cambios y ofreciendo migraciones automáticas, como hace desde siempre, pero cualquiera que haya hecho una migración de alguna app mediana, sabe que no son perfectas y lleva tiempo meterlas en cintura.
Como siempre, hay opiniones para todos los gustos: algunos desarrolladores agradecen mucho el cambio porque les ayudará a poder seguir el ritmo. Otros, por el contrario, temen majors más pesadas y penosas.
La IA, parte de la decisión
La gente de Angular menciona de forma expresa otro motivo importante para esta decisión: un ciclo de actualizaciones más largo da más estabilidad de API a los desarrolladores que trabajan con flujos agénticos (agentes de IA que escriben, modifican o ayudan a mantener código). O sea, hoy en día debería ser básicamente todo el mundo.
Tiene mucho sentido. Un agente, igual que un desarrollador, obtiene mejores resultados si la documentación, los ejemplos y las APIs públicas permanecen estables durante más tiempo. Con menos cambios incompatibles durante un año, hay menos posibilidades de que una receta válida hace unos meses genere código desactualizado en poco tiempo.
Conclusiones
La conclusión práctica es que lo mejor es tratar de mantener las minors al día, para que los pequeños cambios que no rompen compatibilidad se vayan incorporando a tu aplicación. Además no debes perder de vista las "deprecaciones" para que no se te acumulen. Y, por supuesto, reserva unos días para la actualización major al año. Parte de tu mes de junio sabes que vas a tener que dedicarlo a esto...
Yo siempre he sido bastante crítico con ese ritmo de actualizaciones de 2 majors al año, que también sigue Java, por ejemplo, y siempre me ha gustado más el ritmo anual que sigue .NET, más que nada por las ventajas que menciono antes en este post.
Pero, en realidad, a mí no me gusta nada que las versiones grandes tengan que tener una cadencia determinada. Me parecía más natural no tener una fecha de actualización concreta por narices. Más que nada, porque tenerla fuerza de manera artificial esos hitos, y a veces puede ser más interesante sacar versiones antes si hay cosas grandes importantes, o tardar más si no hay grandes funcionalidades que rompan la compatibilidad hacia atrás.
Por otro lado entiendo perfectamente que tener una fecha marcada en el calendario ayuda mucho a la planificación y, sobre todo, facilita fijar las fechas límite de soporte para los mantenedores. Además, dado que hoy en día casi todo el desarrollo (y desde luego el de Angular) se realiza en abierto y podemos ir viendo con mucho tiempo en qué cosas nuevas se trabaja, tener un año de margen nos permite no tener que estar tan encima.
Así que, personalmente, soy de los que está muy contento con el cambio, y me parece una sabia decisión. Mientras tanto nosotros iremos actualizando el curso de Angular de campusMVP.es con las novedades relevantes de todas las versiones: tanto minor como major, para poder estar siempre a la última.
Enlaces de referencia