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

Le , par Michael Guilloux, Chroniqueur Actualités
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.


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


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.


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 ?

Qu’en pensez-vous ?

Voir aussi :

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


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de TheLastShot TheLastShot - Membre averti https://www.developpez.com
le 16/12/2016 à 19:09
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" ?
Avatar de dukoid dukoid - Membre chevronné https://www.developpez.com
le 16/12/2016 à 19:15
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é !
Avatar de scandinave scandinave - Membre averti https://www.developpez.com
le 16/12/2016 à 20:06
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
Avatar de Uther Uther - Expert éminent https://www.developpez.com
le 16/12/2016 à 21:33
Citation Envoyé par TheLastShot Voir le message
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.
Avatar de Marco46 Marco46 - Expert éminent https://www.developpez.com
le 16/12/2016 à 23:01
Citation Envoyé par TheLastShot Voir le message
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.
Avatar de TheLastShot TheLastShot - Membre averti https://www.developpez.com
le 17/12/2016 à 1:43
Citation Envoyé par Uther Voir le message
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)...
Avatar de Jitou Jitou - Membre averti https://www.developpez.com
le 17/12/2016 à 6:35
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é.
Avatar de scandinave scandinave - Membre averti https://www.developpez.com
le 17/12/2016 à 9:03
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.
Avatar de dukoid dukoid - Membre chevronné https://www.developpez.com
le 17/12/2016 à 9:36
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 !

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 !
Avatar de palnap palnap - Membre actif https://www.developpez.com
le 17/12/2016 à 12:53
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
Offres d'emploi IT
Développeur android H/F
Oodrive - Bretagne - Vannes (56000)
Developpeur App Engine, Google Apps, Golang
Business Cloud - Ile de France - Boulogne-Billancourt (92100)
Ingénieur en développement java j2ee (h/f)
Atos - Aquitaine - Bordeaux (33000)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil