Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

136PARTAGES

7  0 
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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Uther
Expert éminent sénior 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.
5  0 
Avatar de dukoid
Membre émérite 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é !
2  0 
Avatar de scandinave
Membre éclairé 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
1  0 
Avatar de Marco46
Expert éminent sénior https://www.developpez.com
Le 17/12/2016 à 16:46
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 :
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.
1  0 
Avatar de scandinave
Membre éclairé https://www.developpez.com
Le 17/12/2016 à 20:46
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.
1  0 
Avatar de Marco46
Expert éminent sénior 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.
0  0 
Avatar de TheLastShot
Membre extrêmement actif 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)...
0  0 
Avatar de Jitou
Membre confirmé 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é.
1  1 
Avatar de scandinave
Membre éclairé 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.
0  0 
Avatar de dukoid
Membre émérite 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 !
0  0