Il n’y aura pas d’Angular 3, Google prévoit de passer à la version 4.0 prévue pour mars 2017

Version imprimable

Voir 40 message(s) de cette discussion en une page

16/12/2016, 16h48
Michael Guilloux

Il n’y aura pas d’Angular 3, Google prévoit de passer à la version 4.0 prévue pour mars 2017

Il n’y aura pas d’Angular 3, Google prévoit de passer à la version 4.0 prévue pour mars 2017
et qui devrait être compatible avec Angular 2

En septembre dernier, Google a livré la version stable d’Angular 2.0, deux ans après l’avoir annoncée. Angular 2.0 devrait permettre de développer les applications plus rapidement et de les rendre plus maintenables. Le framework JavaScript libre et open source développé par Google apporte également des gains de performances énormes, obtenus toutefois au prix de la réécriture de la version 1. Cela a introduit une rupture de compatibilité avec Angular 1 ; laquelle rupture inquiète de nombreux développeurs, même si Google essaie de les accompagner avec des outils pour faciliter la migration.

Google a profité de la sortie d’Angular 2 pour évoquer les nouveautés et améliorations à venir dans la prochaine version du framework. Si l’on s’attendait à ce que cette version soit Angular 3, Google a annoncé lors de la conférence NG-BE 2016 sur Angular que le framework JavaScript va passer de la version 2 à la version 4. Il n’y aura donc pas d’Angular 3, mais pourquoi ?

Igor Minar, responsable de l’équipe Angular de Google, en a donné les raisons au cours de la conférence Angular qui a eu lieu la semaine dernière en Belgique. Minar explique cela par la volonté d’aligner tous les paquets Angular sur le même numéro de version. Ce qui sera plus facile à maintenir et aidera à éviter toute confusion à l'avenir. Il faut en effet noter que les bibliothèques Angular de base sont hébergées dans un seul dépôt GitHub, et elles sont toutes à la version v2.3.0, sauf le paquet @angular/router qui est actuellement à la version v3.3.0.

http://www.developpez.com/public/ima...4-versions.png

L'équipe Angular a donc décidé de passer directement à Angular 4. En procédant ainsi, tous les paquets de base seront alignés sur la même version.

Le changement brutal entre Angular 1 et Angular 2 fait désormais partie du passé

Selon Minar, l'équipe Angular envisage, entre autres, de passer dans un avenir proche de TypeScript 1.8 à TypeScript 2.1 ou même 2.2. Cela devrait introduire des changements de rupture, mais le responsable Angular chez Google veut avant tout rassurer les développeurs. Minar promet que les changements de rupture ne seront pas aussi douloureux que lors du passage d’Angular 1 à Angular 2, qui a nécessité une réécriture totale du framework avec de nouvelles API et de nouveaux modèles.

« Passer de la version 2 à la version 4, 5 ... ne sera pas comme changer de version à partir d’Angular 1 », rapporte Juri Strumpflohner, un membre éminent de la communauté Angular, dans un billet publié sur le blog officiel d’Angular. Faisant un retour sur l’intervention de Minar à la conférence Angular, Juri explique que pour les futures versions, « ce ne sera pas une réécriture complète, ce sera simplement un changement dans certaines bibliothèques de base, qui va exiger un changement de version majeure. De plus, il y aura des phases de dépréciation appropriées pour permettre aux développeurs d’adapter leur code ».

Toujours dans le but de faciliter la migration vers les nouvelles versions, l’équipe Angular de Google utilise en interne un outil pour gérer de manière automatique les mises à niveau, même en cas de changements de rupture. L’outil devrait être disponible pour tous l’année prochaine.

Même si Google prévoit un outil pour faciliter les migrations vers les nouvelles versions du framework JavaScript, l’équipe Angular affirme que la version 4 sera aussi compatible que possible avec Angular 2. L’idée est en fait de veiller à ce que les futures versions n’introduisent que des changements de rupture minimes.

La sortie d’Angular 4 prévue pour mars 2017, et une version majeure tous les six mois

http://www.developpez.com/public/ima...veschedule.png

Angular 4 devrait être disponible le 1er mars 2017 conformément au calendrier de sortie établi, et la première bêta devrait déjà être disponible. Le plan est de sortir une version majeure tous les six mois. Ce qui annonce Angular 5 vers septembre/octobre 2017 et Angular 6 pour mars 2018.

Après la sortie d’Angular 2, Google a décidé d’adopter le versionnage sémantique pour la gestion des versions de son framework JavaScript. Avec cette nouvelle méthode de gestion des versions, chaque version d’Angular sera composée de trois numéros. Le premier correspond à une version majeure qui est incrémentée lorsqu’il y a des changements de rupture. Le second correspond à une version mineure qui est incrémentée en cas de nouvelles fonctionnalités sans changement de rupture. Et le dernier numéro est incrémenté à chaque version qui corrige seulement des bogues.

http://www.developpez.com/public/ima...ar4-semver.png

Avec la fréquence de sortie des versions majeures, cela risque de créer plus de confusion à l'avenir. Minar suggère donc de ne pas rester accroché aux numéros de versions et d’appeler le framework tout simplement Angular, sans indiquer de numéro de version. « Ne l'appelons pas AngularJS, ne l'appelons pas Angular 2, parce que comme nous allons publier de plus en plus de versions, ça va être super déroutant pour tout le monde », dit-il. Minar recommande d’utiliser les numéros de versions uniquement quand cela est vraiment nécessaire pour éviter toute ambiguïté.

Source : Blog Angular

Et vous ?

:fleche: Qu’en pensez-vous ?

Voir aussi :

:fleche: La version finale d'Angular 2.0 désormais disponible, l’équipe Angular évoque déjà les prochaines nouveautés et améliorations du framework JavaScript
16/12/2016, 19h09
TheLastShot

C'est devenu une mode de sauter des versions ?
PHP 6, Windows 9, ...
Sérieusement c'est quoi l'intérêt ? C'est pas comme si on avait pu avoir une preview d'angular 3 et qu'ils avaient tout à coup de changer totalement le framework... La version 2 est encore en béta ! Ils auraient pu juste sortir la v4 en disant que c'était la 3, on aurait rien vu !
Alors pourquoi ils font ça ? Pour la hype ? Pour qu'on se dise "Oh mon dieu c'est fout ce qu'ils bossent vite" ?
16/12/2016, 19h15
dukoid

TheLastShop, car ils ont fais l'erreur de nommer un package sur le routing en version 3, du coup c'est pour remettre tout au même niveau avec la version 4

le choix d'évoluer sans cesse pour être au top
j'espère que la doc officielle sera aussi versionné !
16/12/2016, 20h06
scandinave

La version 2 est en Final. Je l'utilise tout les jours. C'est juste le top. Il manque juste une bibliothèque de composant prête à l'emploi et complète. Par contre l'outil de gestion de projet Angular-cli, lui, est toujours en beta
16/12/2016, 21h33
Uther

Citation:

Envoyé par TheLastShot

C'est devenu une mode de sauter des versions ?
PHP 6, Windows 9, ...
Sérieusement c'est quoi l'intérêt ? C'est pas comme si on avait pu avoir une preview d'angular 3 et qu'ils avaient tout à coup de changer totalement le framework... La version 2 est encore en béta ! Ils auraient pu juste sortir la v4 en disant que c'était la 3, on aurait rien vu !
Alors pourquoi ils font ça ? Pour la hype ? Pour qu'on se dise "Oh mon dieu c'est fout ce qu'ils bossent vite" ?

Tu as pris la peine de lire l'article avant de râler?
C'est quand même expliqué de manière plus que claire.
16/12/2016, 23h01
Marco46

Citation:

Envoyé par TheLastShot

C'est devenu une mode de sauter des versions ?
PHP 6, Windows 9, ...

Ce n'est pas comparable. Ils essaient de suivre semver ... Enfin ils essaient, ça n'a aucun sens de vouloir que toutes leurs librairies aient le même n° de version. Ça n'a véritablement aucun sens. Le n° de version est une information technique. Ils essaient de faire matcher les n° pour des raisons marketing, moralité c'est du grand n'importe quoi. On pourrait très bien en être à angular 10.2.18 dans 6 mois on en a rien à cirer, ça veut juste dire qu'il y aurait eu 8 breaking changes depuis la version 2 ce qui permet(trait) de bénéficier pleinement de la configuration des package.json et bower.json de npm et bower.

Ca n'a pas non plus de sens de vouloir planifier un passage de version majeure. Ils feraient mieux de donner des noms à des scopes fonctionnels et communiquer sur cette base.

Très déçu par Google sur ce sujet, ils font vraiment n'importe quoi pour le coup.
17/12/2016, 01h43
TheLastShot

Citation:

Envoyé par Uther

Tu as pris la peine de lire l'article avant de râler?
C'est quand même expliqué de manière plus que claire.

Oui je l'ai lu mais justement, pour moi ça n'a aucun sens. Le but du versionning de cette forme Major.Minor.Patch, c'est de donner une sémantique à chaque version. Un nouveau patch signifie qu'il n'y a aucune modification au niveau des fonctionnalités, mais qu'il y a eu résolutions de bugs. Une mineure correspond à un changement fonctionnel rétrocompatible (ajout de fonctionnalités, dépréciation de fonctionnalités qui seront supprimées à la prochaines majeurs, etc.). Et enfin une majeure implique qu'il y a eu des modifications si importante qu'il n'y a plus de rétrocompatibilité.

Mais la façon de faire d'angular, en alignant à chaque fois les majeures et mineures de toutes les bibliothèques officielles, c'est totalement absurde, car on peut se retrouver avec de nouvelles mineures sur certaines bibliothèques alors qu'il n'y a aucune raison, en dehors de l'alignement, ce qui fait perdre tout le côté sémantique...

Surtout qu'ils parlent eux-même d'utiliser le versionning semantique, pour le coup c'est totalement raté (d'ici 3 mois, on sera à la version 35)...
17/12/2016, 06h35
Jitou

Assez d'accord avec le premier commentaire, tout ceci sent la stratégie de "hype" d'un framework pas encore mure (v2.0) et mis en oeuvre ici pour maintenir la communauté de développeur en haleine. Pour l'instant je ne vois pas d'adoption massive de Angular 2.0 au niveau des projets réels d'entreprise dans un avenir proche du coup cela laissera peut être la place à un nouveau venu sur le marché des frameworks javascript pourtant déjà bien saturé.
17/12/2016, 09h03
scandinave

Ce n'est pas totalement absurde. L'autre framework concurrent, Ember, fonctionne de la même manière. Le problème c'est que sans version identique, cela devient très compliqué de faire une mise à niveau manuelle du projet. Cela demande de monter chaque sous-dépendances une par une afin de vérifier que les versions fonctionnent bien entre elles. Avec des versions identiques plus de soucis. Jusqu’à présent le seul moyen simple de faire une mis à niveau du projet était de créer un nouveau projet via Ember-cli ou Angular-cli et de comparer les fichiers package.json. Seulement ces outils ne sont que rarement à jour avec la dernière version du Fraemwork.
Il faut voir ça comme un projet global (angular) divisé en module ( Router, compiler etc... ). Du coups la version est celle du projet global. Elle est juste répercutée sur les sous-modules. En acceptant ce fait, on à bien le respect de la version majeur, mineur, bugfixe du projet global.
17/12/2016, 09h36
dukoid

je rajouterai une chose à ne surtout pas négliger c'est la doc.
au moins, on aura une doc classé par version majeur et non pas, un mélange avec des versions taguées en 3 et d'autres en 4. le bordel ! :aie:

En prenant l'exemple sur Symfony ou la courbe d'évolution est lui aussi rapide, la doc est classée par version majeur et aussi par version mineur et c'est le l'idéal pour ne pas tout mélanger !
17/12/2016, 12h53
palnap

En lisant entre les lignes, ça veut donc dire qu'ils vont casser la compatibilité tous les 6 mois... Ca me semble un peu trop rapide comme cycle. Ca risque d'inciter les gros projets à se bloquer sur une version majeure antérieure et ça risque d'engendrer pas mal de problème de fragmentation, notamment au niveau des composants & bibliothèques tierces
17/12/2016, 13h16
grunk

Citation:

Envoyé par TheLastShot

La version 2 est encore en béta !

La version 2.0.0 est sortie le 14 septembre (après 7rc) , elle n'est donc plus officellement en beta depuis cette date.

Citation:

Envoyé par palnap

Ca me semble un peu trop rapide comme cycle

Je trouve aussi. Pour moi Angular2 n'est qu'une infime partie de mon job et j'ai pas spécialement de temps à consacrer pour me maintenir à jour tous les 6 mois avec une version majeure.
Après je conçois aussi que l'ecosystème js est en pleine ébullition et qu'il faut être à la pointe pour se distinguer de tous les autres , mais d'un point de vue industriel c'est difficile de commencer un projet qui aura une durée de vie de plusieurs années avec des fw qui peuvent changer drastiquement tous les 6 mois.
Du coup pour le moment je met à jour ma version d'angular tant qu'elle implique pas de changement dans le code.
17/12/2016, 16h46
Marco46

Non les gars stop lol

Une incrémentation du numéro de version majeur signifie qu'il y a au moins un breaking change. Pas que le framework dans son ensemble n'est plus compatible avec la version précédente.

Par exemple si je prends le changelog de la 1.6.0 par rapport à la 1.5.9, on a une liste de breaking changes dans le changelog, en voici un :

Citation:

remove deprecated callback methods: success()/error()

Cela signifie qu'en passant de la 1.5.9 à la 1.6.0 les callbacks success() et error() de $http ne fonctionnent plus car deprecated. Il faut désormais passer .then() et .catch().

Si angular 1 avait respecté semver et si il n'y avait eu que ce seul breaking change entre la 1.5.x et la 1.6.x, ils auraient du nommer la 1.6.0 en 2.0.0.

Il y a des breaking changes très souvent dans beaucoup de librairies, passer d'une version majeure à une autre sous semver n'est pas comparable à passer de ES5 à ES6 par exemple.

Sur la 1.x des breaking changes il y en avait très souvent, nettement plus fréquemment que tous les 6 mois. Ca ne pose pas de problèmes particuliers, généralement c'est l'affaire de 1 ou 2 jours maximum pour réaliser les modifications nécessaires à une montée de version.

Le problème dans cette histoire c'est qu'il y a trop de confusion dans tout ce bordel. AngularJS (1.x) et angular 2 sont des frameworks différents. Et le nommage est absolument dégueulasse. On ne devrait pas parler de angular 2 mais de angular tout court.

En fait il y a AngularJS qui a un système de notation sur 3 chiffres qui ne respecte pas semver (puisque tout le temps en 1.y.z).
Et il y a angular qui est parti direct sur 2.y.z et qui tente de respecter semver mais qui a été nommé improprement angular 2.
17/12/2016, 20h46
scandinave

Citation:

Je trouve aussi. Pour moi Angular2 n'est qu'une infime partie de mon job et j'ai pas spécialement de temps à consacrer pour me maintenir à jour tous les 6 mois avec une version majeure.
Après je conçois aussi que l'ecosystème js est en pleine ébullition et qu'il faut être à la pointe pour se distinguer de tous les autres , mais d'un point de vue industriel c'est difficile de commencer un projet qui aura une durée de vie de plusieurs années avec des fw qui peuvent changer drastiquement tous les 6 mois.
Du coup pour le moment je met à jour ma version d'angular tant qu'elle implique pas de changement dans le code.

Mieux vaux 1 ou 2 "breaking change" tout les 6 mois, qui prendront 2 jours à corriger la plupart du temps, que de devoir tout recoder parce que une version à mis trop de temps à sortir. Ceux qui avait commencés un projet sur AngularJs(1.x) juste avant la sortie de Angular2 doivent s'en mordent les doigts.

Encore une fois, je cite EmberJs qui pour moi est en avance sur tout ce qui est processus et industrialisation du développement. Il sont passé par la, il y a 1 ans environ lors du passage à la version 2 du Framework. Pour contenter tout le monde, ils ont adopter le principe de Ubuntu ou Firefox par exemple, qui livre une rolling release tout les 6 mois et une Extended Support Release qui est soutenue pendant 1 ans 1/2. Cela permet à des entreprises dont le cycle de développement est moins agile de pouvoir suivre la cadence.
18/12/2016, 02h50
Marco46

Citation:

Envoyé par scandinave

Ceux qui avait commencés un projet sur AngularJs(1.x) juste avant la sortie de Angular2 doivent s'en mordent les doigts.

Je vois pas tellement comment on peut envisager de développer un produit pro avec Angular2 en l'état actuel. Il n'y a aucune librairie disponible en version stable. Tout est en alpha ou beta au mieux à l'exception de Angular2 lui-même.

On est dans la même situation qu'il y a 4 ans lorsque AngularJS était en version 1.0.0. C'est sympa pour faire des PoCs, point barre. Il faut attendre au minimum d'avoir ng-bootstrap ou material2 (selon si on préfère bootstrap ou material) en stable. Et encore ...

Au mieux pour faciliter la migration future on peut faire du 1.6 avec Babel.
19/12/2016, 12h10
palnap

Bien d'accord, pour l'instant ça parait moins risqué de commencer un projet sur AngularJS 1.5 ou 1.6 avec ES6 + utilisation des composants pour se garder la possibilité ultérieurement de migrer vers Angular2.

Le seul cas où je verrai Angular2 nécessaire en début de projet serait une application gourmande en ressources avec un point de vigilance sur les perfs. Et là encore, je suis pas sûr de pas choisir React :mrgreen:
19/12/2016, 12h43
dukoid

C'est fini le temps ou les frameworks et les langages étaient statiques durant de longue période.
Depuis 3-4 ans, c'est une nouvelle ère qui a commencé : place à la multiplication de frameworks et d'outils avec une évolution rapide et perpétuelle.

java, .NET, PHP, JS...
19/12/2016, 12h53
hotcryx

Ils se sont bien plantés la gueule avec la version Router, mais personne le dit dans l'article :mouarf:
19/12/2016, 12h56
hotcryx

Citation:

Envoyé par dukoid

C'est fini le temps ou les frameworks et les langages étaient statiques durant de longue période.
Depuis 3-4 ans, c'est une nouvelle ère qui a commencé : place à la multiplication de frameworks et d'outils avec une évolution rapide et perpétuelle.

java, .NET, PHP, JS...

Côté JS ça évolue trop vite et part dans tous les sens chacun créant de nouveaux FW basés sur les autres, incorporant certaines lib et pas d'autres...
Ca risque de devenir problématique avec npm (heureusement qu'il existe).
19/12/2016, 13h23
CyberDenix

Google Polymer bien meilleur que Angular

Depuis que Google a sorti Polymer, il n'y a plus aucun intérêt aux Angular, React et consors.

Google Polymer les enterre tous, et de loin.
Surtout quand il est utilisé conjointement avec Google Firebase.

:D

Voir 40 message(s) de cette discussion en une page