La version 4 d’Angular est disponible depuis le 23 Mars 2017. Etant donné que la version précédente du framework était la version n°2, on peut se demander si les équipes de Google n’ont pas oublié de publier une version 3 ! 🤔

Le fonctionnement des versions avec Angular peut paraître particulier au début. Pourquoi passé de la version 2 à la version 4 directement ? Surtout après avoir développer Angular qui n’était pas compatible avec son petit frère AngularJS !

Le fonctionnement des versions d’Angular

Google a publié un billet sur le blog officiel d’Angular pour expliquer le fonctionnement du versioning d’Angular.

Le paradoxe auquel sont confrontés les équipe de Google est le suivant :

Comment continuer de faire évoluer Angular, tout en assurant de la stabilité pour les développeurs ?

Pour résoudre ce paradoxe et répondre à ces deux objectifs apparement contradictoires, Google a décidé de mettre en oeuvre un système de versioning sémantique et un nouveau processus de développement. L’objectif est de clarifier la roadmap du développement d’Angular et de ne plus mettre les développeurs en difficultés.

Dès la sortie de Angular 2.0.0, les équipes de Google ont adopté les mesures suivantes :

  1. Utilisation d’un système de versioning sémantique.
  2. Les cycles de publications sont maintenant basés dans le temps et peuvent donc être planifiés à l’avance.
  3. Mise en place d’une politique de dépréciation pour les futurs éléments obsolètes, afin d’être informé en avance des modifications de l’API.
  4. La distinction entre les API stables et expérimentales a été clarifié.
  5. L’étendue de l’API publique a également été clarifié.

Versioning sémantique

Pour être concis, le versioning sémantique, c’est : MAJOR.MINOR.PATCH.

Concrètement, cela signifie que les numéros de versions ont une signification particulière :

  • Les versions de patch ne modifient pas les fonctionnalités du programme, ce sont des correctifs.
  • Les versions mineurs ne contiennent que des modifications ou des ajouts de fonctionnalités.
  • Les versions majeurs sont réservées aux modifications de rupture.

Si vous souhaitez être un As du versioning système, voici la page officielle du versioning sémantique (en Anglais par contre 😅).

Cycles de publication basés sur le temps

En plus d’utiliser le versioning sémantique, Google nous propose un calendrier des versions à venir d’Angular, pour nous permettre de nous organiser au mieux :

release-cycle.png
Calendrier 2017 des versions à venir !

On remarque que Angular 5 est prévu pour Septembre 2017, Gloups ! 😮

Bon, au moins cette fois nous sommes prévenus. Plus précisément, voici ce qui nous attend :

  • En général, on peut s’attendre chaque semaine à 3 mises à jour mineures.
  • Tous les 6 mois une nouvelle version majeur !
  • Des versions Betas et Release Candidate seront proposées pour chaque nouvelle version majeure et mineure.

Pour résumé, ce système des versions basées sur le temps permet aux développeurs qui le veulent un accès à de nouvelles fonctionnalités bêta dès qu’elles sont prêtes, tout en maintenant la stabilité et la fiabilité de la plate-forme pour les utilisateurs en production.

Politique de dépréciation (« Deprecation Policy »)

(Une politique de dépréciation permet d’organiser au mieux l’abandon d’éléments amenés à être obsolète.)

Les changements de rupture sont perturbateurs, mais sont nécessaires aux équipes qui travaillent sur Angular pour continuer à innover : adopter les meilleures pratiques, modifier les différentes dépendances du framework, et s’adapter au changement du Web lui-même. Afin de rendre ces transitions plus prévisibles, Google a mis en œuvre une politique de dépréciation.

Ils essayent de minimiser le nombre des modifications de rupture dans Angular, en prenant les mesures suivantes pour aider les développeurs :

  • Lors de l’annonce d’une dépréciation sur tel ou tel élément, Google s’engage à publier une façon de mettre à jour les éléments concernés. Pratique !
  • Ils continueront de supporter l’utilisation actuel de l’API (c’est-à-dire que votre code continuera de fonctionner ! 😎) durant la période de transition, et vous aurez toujours plus de 6 mois (deux versions majeurs) pour vous mettre à jour.
  • Les mise à jour de dépendances avec modifications de ruptures sont réservées pour les versions majeurs. Par exemple, lors de la prochaine publication majeure (Angular 5 en septembre ou octobre 2017), la dépendance à TypeScript sera désormais la version 2.

APIs Stables vs Expérimentales

Si vous allez sur la documentation officielle de l’API, vous remarquerez que certaines API s sont noté comme « EXPERTIMENTAL » :

Capture d_écran 2017-06-28 à 11.57.30
Certaines API sont « EXPERIMENTAL » et d’autres non.

Les APIs expérimentales sont suffisamment solide pour être utilisé en production, mais elles nécessitent des tests « sur le terrain » pour valider qu’elles fonctionnent bien pour divers cas d’utilisation.

Les APIs expérimentales respectent le versioning sémantique mais pas la politique de dépréciation. Si vous utilisez une API expérimentale, vous devez vous attendre à des changements, dont certains pourraient ne pas avoir d’issus (c’est-à-dire que Google ne vous dira pas comment les mettre à jour). Cela dit, Google essaye bien sûr de minimiser ces perturbations et documentent les modifications apportées à l’API.

Actuellement, même si une partie de l’API est encore expérimentale, aucun des cas d’utilisation de base nécessite l’utilisation d’APIs expérimentales. Des exemples d’APIs expérimentales sont : le debugging, le support des web workers, i18n, http et les animations. À mesure que ces API seront plus matures et auront plus d’exposition dans le monde réel, elle passeront de la catégorie expérimentale à la catégorie stable.

Étendue de l’API publique

Angular est une collection de nombreux paquets différents, de sous-paquets et d’autres outils. Pour clarifier ce qui est publique de ce qui ne l’est pas, Google a clarifié tout ça dans cette liste des APIs expériementales.

Conclusion

J’espère que ce petit guide vous permettra d’y voir plus clair sur le fonctionnement du versioning d’Angular. Cela devrai vous permettre de mieux vous organiser pour vos futurs développements.

SOURCE : Voici le lien vers l’article original sur le blog officiel d’Angular.

 

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s