Nouvelle politique de gestion des versions

La semaine dernière est sortie la version 8.2.0-rc2 de Drupal, c'est l'occasion de revenir sur la nouvelle politique des cycles de release et ce que cela implique.

Bien avant la sortie de la version 8.0, la communauté s'est penchée sur les solutions qu'elle pouvait apporter au problème du manque de prédictibilité des dates de sortie. La politique depuis des années consiste à dire qu'une version majeure est publiée (une version majeure étant la 7.0 ou 8.0) lorsqu'elle est prête. L'adage consacré est le suivant : «Quand est ce que la version Drupal 8.0 sera prête ? Elle sera prête quand elle sera prête.». La définition de «prêt» étant liée au nombre de bugs critiques identifiés dans la listes des issues de Drupal. Tant que son total n'est pas égal à 0, une version majeure ne peut pas être envisagée. Plutôt aléatoire tout ça… autant dire que cela n'avance personne, et surtout pas le monde de l'entreprise.

Oui mais voilà, depuis la fin du cycle de Drupal 6 et l'avènement de Drupal 7, l'utilisation de Drupal a explosé, peu de sites qui nécessitaient un CMS et avec une taille de projet de plusieurs mois se lançaient avec autre chose que Drupal. Bonne nouvelle, me direz-vous, et vous aurez raison. Sauf que, comme le disait notre bon ami Spiderman : «avec de grands pouvoirs viennent de grandes responsabilités». Les années passant, l'usage de Drupal a continué de croître et la suite logique a été donc le lancement des développements de la branche 8.x.
Un cycle de développement d'une version majeure prenant plusieurs années, les choses ont démarré comme à l'époque de Drupal 7 : plusieurs mois ont passé puis l'impatience a monté en flèche dès les premières annonces de l'utilisation de composants de Symfony au sein de Drupal 8 braquant ainsi beaucoup de projecteurs notre CMS fétiche. Les mois passèrent et avec eux les dizaines de milliers de lignes de code se sont accumulées. Le problème avec Symfony étant qu'une fois que vous mettez le doigt dans l'engrenage, il fait sens d'utiliser toujours plus de ses composants, repoussant d'autant la ligne d'arrivée du travail de réécriture. Conscients du problème soulevé et déjà rencontré lors de la mise au monde de Drupal 7 (satané Overlay qui a repoussé la publication de Drupal 7 de plusieurs mois), Dries et quelques personnes clés de la communauté ont pris le problème à bras le corps. Fin 2013, le principe d'introduire des versions sémantiques pour Drupal a été acté, la première version de 8.x ne serait donc pas Drupal 8.0 mais Drupal 8.0.0.

Qu'est-ce que ça change concrètement ?

Le modèle de Drupal jusqu'à présent excluait tout ajout dans le cœur du système entre deux versions majeures. De fait, il a fallu attendre 5 ans la sortie de Drupal 8 pour que des fonctionnalités essentielles au web d'aujourd'hui soient intégrées. Or, le web évolue plus vite que jamais et les besoins et usages des clients progressent rapidement. Les versions sémantiques offrent une nouvelle souplesse en introduisant un nouvel échelon dans l'évolution du logiciel.

Une version sémantique est un code découpé en trois parties numériques, séparées par un point, par exemple 8.1.10. On appelle la première partie, celle de gauche, la version majeure. La partie centrale est appelée version mineure et la partie de droite version de patch. Pour faire le parallèle avec l'ancien système, nous n'avions que les versions majeures et les versions de patch.

En ce qui concerne le contenu de ces versions, les choses sont plus claires :

• les versions majeures sont garantes de la compatibilité. Ainsi, quelle que soit la version mineure ou de patch de l'application, tant que vous conservez la même version majeure, le code que vous avez pu écrire doit toujours être compatible ;
• les versions mineures représentent les évolutions fonctionnelles du cœur. Il est permis d'ajouter de nouvelles fonctionnalités, qu'elles soient expérimentales ou stables (nous en détaillerons quelques unes dans un prochain article) ;
• les versions de patch corrigent des bugs ou des failles de sécurité a fil de l'eau.

La seule entorse acceptée à ce nouveau système est le cas où un correctif de sécurité venait à rompre la compatibilité avec les précédentes versions. Dans ce cas et uniquement dans celui-ci, une telle modification serait acceptée dans le cadre d'une version de patch mais tenterait d'être limitée au maximum en redoublant d'efforts de communication et en mettant en place des outils, lorsque cela est possible, pour amoindrir l'impact sur les sites existants.

À quelle fréquence les versions vont-elles évoluer ?

L'autre avantage majeur de cette décision est qu'il permet de mettre en place un calendrier de publication des versions plus ouvert. La communauté a donc décidé qu'une nouvelle version mineure (8.1.0, 8.2.0, 8.3.0, etc.) sortirait tous les 6 mois. Les versions de patch (8.2.1, 8.2.2, 8.2,3 etc.) sont publiées quant à elles chaque premier et troisième mercredi du mois pourra être publiée respectivement pour les versions liées à des correctifs de sécurité ou de bugs.

Pour chaque version mineure, le cycle de release reste le même que pour une version majeure : la première version est une alpha, puis suivent les statuts beta, Release Canditate (rc) et la release officielle. Les développeurs peuvent donc maintenant savoir à l'avance quand réserver du temps dans leur calendrier pour préparer les montées de versions.

Crédits :

• image d'illustration du versionning sémantique tirée d'un article de blog au sujet des versions de Bower ;
• diagrammes illustrant les cycles de release de Drupal tirés de la documentation officielle.