Angular 4 sale en marzo

El otro día quede sorprendido al leer que Angular 4 salía en marzo. El motivo de mi sorpresa es que recientemente salió la versión final de la 2 asi que no entendía porque saltaban rapidamente al 4 (y sin pasar por el 3).

Investigando por internet esto fue lo que encontré en el blog de Angular.

¿Por qué angular 4? ¿Qué paso con Angular 3?

Angular utiliza SEMVER

Hace tiempo atras, en septiembre, cuando el nuevo Angular fue lanzado, el equipo de Angular anunció tambien que estarían cambiando la nomenclatura de versiones a Versionado Semántico (SEMVER).

Como el nombre ya lo explica, Versionado Semántico es todo acerca de darle sentido a los números de versiones. Esto permite a los desarrolladores no solo razonar sobre cualquier actualización que hagan, sino que además cualquier herramienta como NPM puede entenderlo y hacer actualizaciones de forma automática y segura.

Una versión semántica consiste en tres números:

Cuando arreglas un bug y lo lanzas a producción, incrementas el último número, si agregas una neuva característica incrementas el segundo, si agregas un cambio disruptivo debes incrementar el primer número.

Un cambio disruptivo ocurre cuando tu como desarrollador y consumidor de la librería, tienes trabajo que hacer y código por ajustar cuando hay una nueva versión de una librería.

Entonces, ¿Qué significa esto para el equipo de Angular? Como cualquier pieza de software que está en evolución, los cambios disruptivos ocurren en algún momento. Por ejemplo dar un error de compilación para bugs existentes de aplicación que antes no eran notados en la versión anterior del compilador, cualquier cosa, que pueda romper la aplicación existente al actualizar Angular requiere que el equipo aumente el número de versión mayor.

Para ser claros, en este momento, incluso actualizar la versión de TypeScript que usa Angular de la v1.8 a la v2.1 o v2.2 y compilar Angular con el, tecnicamente causaría un cambio disruptivo. El equipo de Angular se toma SEMVER muy, muy seriamente.

Los cambios disruptivos no tienen que ser dolorosos

La gente ha estado siguiendo la comunidad de Angular por un tiempo, y definitivamente sabe de lo que estoy hablando.

Cuando pasamos de Angular 1 a Angular 2, era un cambio completamente disruptivo, con nuevas APIs, nuevos patrones. Eso fue obvio: en ultima instancia Angular 2 fue una rescritura completa.

Cambiando de la versión 2 a la versión 4, 5, no va a ser como cambiar desde Angular 1. No será una rescritura completa, simplemente habrá cambios en algunas librerías del core que van a demandar un cambio del número MAYOR de SEMVER. Además habrá las fases de obsolescencia (marcar como obsoleto ciertos métodos) apropiadas para darles tiempo a los desarrolladores a ajustar su código.

Internamente en Google, el equipo de Angular utiliza una herramienta para manejar las actualizaciones autómaticas, incluso las de cambios disruptivos.

Esto es algo que tiene que planificarse con más detalle, pero el equipo está trabajando duro en hacer que esta herramienta esté disponible para todos, problamente durante este 2017 a tiempo para la versión 5.

Es simplemente “Angular”

Como se habrán dado cuenta, el termino “Angular 2” queda algo obsoleto ahora que llegamos a la versión 4, 5, etc. En lugar de eso deberíamos simplemente nombrarlo “Angular” sin el prefijo de versión.

Es simplemente “Angular”

Además, deberíamos dejar de nombrar librerías en GitHub o NPM con el prefijo ng2-, o angular2-.

Directivas de nombrado

Basicamente de ahora en más, deberías nombrar las versiones de Angular superiores a 2.0.0 simplemente “Angular”. Intentemos evitar usar el número de versión, a menos que sea necesario sacar alguna ambigüedad.

Tres directivas simples:

• Usar “Angular” para versiones 2.0.0 o superior (por ej: “Soy desarrollador Angular”, “Esta es una reunión de Angular, “El ecosistema de Angular crece rápidamente”)
• Utilizar “AngularJS” para referirte a versiones 1.x o anteriores.
• Utiliza el número de versión “Angular 4.0” “Angular 2.4” cuando necesites hablar de una versión espécifica (por ej: hablar de una característica nueva - “Esta es una introducción a la característica X presentada en Angular 4”, o “Propongo este cambio para Angular 5”)
• Utiliza el número de versión SEMVER completo cuando reportes un bug (por ej: “Este problema se presenta desde Angular 2.3.1”)

Toda la documentación - incluída la de AngularJS - se va a alinear con esto en las proximas semanas. Además árticulos de blog, cursos, libros que estén orientados a una versión particular de Angular por Algunar razón considera agregar una linea en el encabezado que declare:

“Este árticulo utiliza Angular 2.3.1”

Esto ayuda a evitar confusión para tus lectores, especialmente cuando escribes acerca de APIs específicas.

¿Por qué no Angular 3?

Las librerías core de Angular viven en un repositorio único de GitHub en https://github.com/angular/angular. Todas ellas están versionadas de la misma forma pero distribuídas como paquetes de NPM diferentes:

Dado con esta desalineación de la versión del paquete router, el equipo de Angular decidió ir directamente por Angular v4. De esta forma, nuevamente, todos los paquetes van a estar alineados para evitar confusiones en el futuro.

También es importante entender como Angular está siendo usado dentro de Google (Se puede ver en esta presentación) Todas las aplicaciones utilizan la versión de Angular igual a la actual en la rama master del repositorio de Angular en GitHub. Cuando un nuevo commit entra en master, va a ser integrado en el repositorio único y gigante de Googgle, donde convive con otros productos tales como AdSense y Maps. Como consecuencia de esto, todos los proyectos que usan Angular internamente en Google van a ejecutar extensivas suites de tests contra esta neuva versión. Esto dota de gran confianza al equipo al momento de lanzar una nueva versión, dado que contendrá la combinación exacta de versiones de los paquetes de Angular que han sido probadas para la batalla dentro de Google. De esta forma, tener versiones alineadas tiene mucho sentido y facilita el mantenimiento con el pasar del tiempo, lo que ayuda al equipo ser más productivo al momento de sacar nuevas características.

Fechas tentativas de Release

El hecho de que los cambios van a llegar, no significan que estarán aquí cualquier otra semana. El equipo de Angular tiene releases basadas en tiempo que ocurriran en tres ciclos.

• Parches lanzados cada semana,
• 3 versiones menores después de cada versión mayor y
• una versión mayor de facil migración contra cambios disruptivos cada 6 meses.

Después de Angular 4.0.0, estas serán las fechas tentativas para proximas releases:

Video: Ver el anuncio por ti mismo:

Conclusión

Hay dos mensajes importantes aquí:

• No te preocupes por los números de versión
• Necesitamos hacer evolucionar a Angular de manera de evitar un cambio como el de Angular 1 a Angular 2, pero debemos hacerlo conjuntamente como comunidad, y de manera transparente, predecible e incremental.