Dans tout projet informatique, la gestion des numéros de releases doit suivre une politique bien définie. Cela facilitera le suivi des versions pour les utilisateurs, les développeurs et toute la communauté autour du projet.

Un peu d'historique..

Sur les projets Drupal (core, modules, thèmes et profiles), il y avait historiquement une convention à suivre concernant les numéros des releases. Ces derniers sont au format suivant “{API compatibility}-{major}.{minor}[-(alpha|beta|RC){number}]”.

Détaillons rapidement les différents composants de ce format : 

• {API compatibility} : Indique le numéro de version majeure de Drupal supportée par le projet (module ou thème,..). Exemple : 7.x ou 8.x .
• {major}.{minor} : Il s’agit ici des versions majeure et mineure du projet. La version majeure commence toujours par 1, et toute incrémentation de la version majeure marque un changement dans le fonctionnement du projet ou une refonte de la structure du code et des données du projet.
  La version mineure commence toujours par 0, et est utilisée pour les corrections de bugs et les changements respectant la rétrocompatibilité avec les précédentes releases.
• [-(alpha|beta|RC){number}] : Généralement avant de lancer une nouvelle fonctionnalité, on génère des releases expérimentales, permettant à la communauté de tester et de réagir avec les mainteneurs du projet en signalant des bugs ou en proposant des correctifs...  Exemple : alpha3, beta1.

Ce format a fait ses preuves durant toutes ces années dans l'écosystème Drupal, mais le vent du changement commençait à souffler lorsqu'on s'approchait de la sortie de Drupal 9. Car à partir des dernières versions de Drupal 8, le choix a été fait pour un passage au Semantic Versioning (SemVer) comme format recommandé pour les projets Drupal. 

Pourquoi donc proposer un nouveau système ?

Avant Drupal 9, la sortie de chaque version majeure du CMS entraîne une perte de rétrocompatibilité avec les versions précédentes, ce qui pousse les autres projets de l’écosystème (modules, thèmes et profiles) à proposer des releases spéciales pour chaque version majeur de Drupal.
Drupal 9 quand à lui, assure la rétrocompatibilité avec la version 8, et du coup on peut rendre un module développé à la base pour Drupal 8 compatible avec la version 9 du CMS en introduisant juste quelques modifications simples (suppression des dépréciations..). C’est donc le moment idéal pour les projets contrib de maintenir une seule version compatible à la fois avec Drupal 8 et 9.
Le système “Semantic Versioning” répond parfaitement à ce besoin, lui qui est déjà adopté par la majorité des projets Open-Source. Il permet de passer à un format standard plus simple : “{major}.{minor}.{patch}[-(alpha|beta|RC){number}]”. 
On abandonne donc le “{API compatibility}” de l’ancien format et on introduit le niveau “{patch}”. Ce dernier commence toujours par 0, incrémenté seulement lorsque la nouvelle release contient des corrections de bugs. La version mineure est incrémentée dans le cas de nouvelles fonctionnalités conservant la rétrocompatibilité avec la version majeure.
Pour les projets existants, lors du passage au système SemVer, il faut absolument incrémenter le numéro de version majeure. Par exemple si la dernière version du module est la 8.x-3.5, la nouvelle release sera donc 4.0.0 .
Prenons l’exemple actuel des releases du module Webform : 

On remarque ici qu’on maintient deux versions stables (en vert) pour Drupal 7 et 8. Sur Drupal 7, Webform est dans la version majeure 4.23, et sur Drupal 8 c’est la version 5.20. 
Le passage au Semantic Versioning se fera donc sur la nouvelle version majeure du module 6.0.0 (en jaune sur l’image).

Autre remarque, on voit que la release 8.x-5.20 est compatible seulement avec les versions de Drupal >= 8.8, sans supporter la version 9 du CMS. Sur cette dernière il faudra utiliser la release 6.0.0 de Webform, compatible avec Drupal >=8.8 et Drupal 9 à la fois.

Comment définir les contraintes de compatibilité avec les versions du core ?

Historiquement dans Drupal on avait la directive “core” sur les fichiers .info (ou info.yml) qui permet de définir les contraintes de compatibilité avec les versions majeures du CMS. Exemple : “core: 7.x“. 
Avec l’arrivée de Drupal 9, on a rapidement eu le besoin de définir des contraintes de compatibilité avec plusieurs versions majeures de Drupal (logiquement 8.x et 9.x à la fois). La nouvelle clé “core_version_requirement” a vu donc le jour sur les fichiers .info.yml à partir de Drupal 8.7.7, pour permettre de définir des contraintes respectant le format Semver de Composer. Exemple “core_version_requirement: ^8.8 || ^9” .

On note qu’il est possible d’implémenter les mêmes contraintes sur le fichier composer.json par rapport au projet “drupal/core”. Si aucune règle n’est définie sur ce fichier, elle sera générée automatiquement lors de la publication de la release en se basant sur la clé “core_version_requirement” :

{
  "require": {
    "drupal/core": "^8.8 || ^9"
  }
}

Conclusion

La communauté Drupal a fait d’énormes efforts pour rendre le plus simplement possible la gestion des releases des projets du CMS. Avec l’adoption du Semver pour les numéros de releases, une autre étape a été franchie, permettant à Drupal de s’approcher de plus en plus des standards implémentés sur les autres projets phares de PHP.