Capítulo 1 - Solo Angular
Cuando salió AngularJS allí por el 2009, era normal ponerle el "JS" en el nombre del framework ya que estaban 100% escritos en JavaScript…
Pero este nombre termino siendo un problema, ya que cuando empezó a crearse "Angular 2" la nueva version de este super poderoso framework, se empezó a escribir en AtScript (https://en.wikipedia.org/wiki/AtScript), pero Microsoft (si aquella evil corp que cambio) creo TypeScript (https://www.typescriptlang.org/) y por el tipado y su robustez el Angular’s Team lo adopto y decidió reescribir todo lo que se había hecho en AtScript aTypeScript…
Por este motivo se tachó el JS del nombre… entonces quedó de AngularJS a Angular 2 … Pero la historia no queda ahí, después de tanto esperar esta nueva versión que cambio muchísimo de la versión anterior, se tomó otra gran decisión.
A partir de ahora se van a sacar versiones consecutivas utilizando el SEMVER, por lo tanto cada 6 meses vamos a tener una versión de Angular nueva … WTF entonces para qué aprendo Angular 2 si Angular 4 está por salir en unos meses, y nuevamente empezamos con un nuevo problema en el nombre…
Igor Minar (https://twitter.com/IgorMinar) , uno de los core team de Angular se encargó en explicar exactamente que es esto de las versiones y porque no deberiamos preocuparnos, si no, que contentarnos …
Pero qué es Semantic Versioning (SEMVER) ?
SEMREV es "Agrega contexto a los números de las versiones". Esto permite a los desarrolladores no sólo razonar sobre cualquier actualización que hacemos, pero incluso podemos dejar que herramientas como NPM lo hagan de manera automática y segura para nosotros.
Una versión semántica consta de tres números:
Siempre que corrijan un error y lo liberen, aumenta el último número, si se agregan una nueva función, aumentan el segundo número y cada vez que liberan un cambio de fuerte aumentan el primer número.
Entonces, ¿qué significa esto?
Software evolutivo, los “breaking changes” se producirán en algún momento. Por ejemplo, al dar un error de compilador para los errores de aplicación existentes que pasaron desapercibidos con la versión del compilador anterior, cualquier cosa, que rompa una aplicación existente al actualizar Angular, requiere que el equipo cambie el número de versión principal.
Sólo para ser claro, como Igor también mencionó en su charla. En este momento, incluso actualizar la dependencia de TypeScript en Angular de v1.8 a v2.1 o v2.2 y compilar Angular con ella, técnicamente causaría un “breaking changes”. Así que están tomando a SEMVER muy, muy seriamente.
Entendiendo esta decisión parecería una locura… cambios constantes… pero en realidad son cambios evolutivos y con retro-compatibilidad… por lo tanto aprender Angular ahora se convierte en algo progresivo (nodeJS hace algo parecido).
Por lo tanto al día de la fecha tenemos una idea de que las nuevas versiones vendrían en poco tiempo
Aquí se puede ver el video en donde explica todo Igor
Entonces cuando estés aprendiendo#Angular, vas a estar aprendiendo algo en constante evolución…
Tienes grandes pros, el framework evoluciona constantemente tal y como lo hacen los navegadores y funcionalidades nuevas… por lo tanto si typescript saca una nueva versión la van a incluir rápidamente, si existe una nueva versión de RxJS pasaría lo mismo, las inclusiones son rápidas y ágiles, y gracias a estoAngular pasa a estar siempre actualizado ,o mejor dicho con actualizaciones "constantes o más rápidas", y de esta forma no estaría mucho tiempo sin una funcionalidad que aparezca en los navegadores.
Algo a tener muy en cuenta es que vamos a tener retro-compatibilidad, por lo tanto actualizar la versión no es botar todo el código y rehacerlo sino que simplemente es tener más funcionalidades para poder aprovechar en nuestros desarrollos.
Last updated
