Versionnage sémantique

Introduction

Exemple de versionnage sémantique de Mediawiki, l'application web qui fait marcher ce wiki et également Wikipedia.

Le versionnage sémantique (de l'anglais semantic versioning) ou gestion sémantique de version est un système conventionnel d'indication de la version d'un logiciel, d'un plugin, d'une bibliothèque ou autre élément technologique avec trois nombres allant de 0 à l'infini séparés par un point.

12.345.678

Chacun de ces nombres est associé à un type de changement par rapport à la version précédente. Dans l'ordre :

1. Le premier nombre représente une modification majeure
2. Le deuxième nombre représente une modification mineure
3. Le troisième nombre représente une correction ou un patch

majeure.mineure.correction

Cette nomenclature conventionnelle essaie de résoudre deux grands problèmes du développement :

• La rétrocompatibilité : si on prend un système d'exploitation en tant que référence, un nouveau logiciel est rétrocompatible si sa version n marche sous Windows 8 et sa version n+1 marche également sous Windows 8. Au contraire, un logiciel n'est pas rétrocompatible si sa version n marche sous Windows 8 mais sa version n+1 nécessite de Windows 10.
• Les dépendances (ou dependencies en anglais) : il arrive souvent que des logiciels s'appuient sur d'autres logiciels (ou plugins ou bibliothèques) pour fonctionner. Par exemple un site web qui ne peut fonctionner correctement qu'à partir d'une certaine version d'un navigateur web est dépendant de la version du navigateur web.

Le versionnage sémantique est souvent utilisé en combinaison avec la gestion de versions.

Les trois types de changements

Le système de versionnage sémantique consiste à incrémenter les trois chiffres de la version selon des règles spécifiques.

Correction

de x.x.1 à x.x.2

On augmente le chiffre de correction x.x.1 à x.x.2 si les modifications apportés respectent la rétrocompatibilité ET s'il n'y a aucune fonctionnalité ajoutée par rapport à la version précédente. Les changements de type correction sont les plus fréquents et peuvent concerner des modifications subtiles telles que :

• Des petits bugs
• Des problèmes de sécurité
• Amélioration du code
• Réduction du temps d'exécution
• Etc.

Version mineure

de x.1.x à x.2.0

On augmente le chiffre de la version mineur de x.1.x à x.2.0 si les modifications apportées respectent la rétrocompatibilité MAIS qu'une ou plusieurs fonctionnalités ont été ajoutées. Veuillez noter que lorsqu'on augmente la version mineure, le chiffre de correction redémarre à 0. Les changements mineurs sont assez fréquents, car ils apportent souvent des corrections à des requêtes d'utilisateurs pour de nouvelles fonctionnalités, sans toucher aux fonctionnalités déjà existantes. Par exemple :

• Pouvoir ajouter le champ "middle name" dans un carnet d'adresse, tout en gardant "first name" et "last name" intacts
• Pouvoir imprimer un document en modalité horizontale, tout en gardant la version verticale intacte et comme choix prédéfini
• Etc.

Version majeure

de 1.x.x à 2.0.0

On augmente le chiffre de la version majeure de 1.x.x à 2.0.0 si les modifications apportées créent des incompatibilités avec la version précédente, que ce soit à cause de nouvelles fonctionnalités ou pas. Dans ce cas également, lorsqu'on augmente la version majeure, la version mineure et la correction redémarre à 0. Les changements majeurs sont les moins fréquents et les concepteurs des logiciels réfléchissent attentivement avant de déployer une nouvelle version majeure justement parce que cela implique de gérer les problèmes de rétrocompatibilité. Dans les cas les plus complexes, le changement de version majeure nécessite l'intervention de l'utilisateur (que ce soit un "client" ou un autre développeur) pour pouvoir s'adapter à la nouvelle version. Exemple :

• Imaginez un carnet d'adresse qui stocke les contacts dans un champ unique "name". Si la nouvelle version sépare le carnet en "first name" et "last name" et ne prévoit plus un champ "name", il faudra établir comment les données disponibles seront départagées entre les nouveaux champs.
• Imaginez une bibliothèque de dessin qui présente les fonctions drawCircle() et drawSquare(). Par souci d'uniformité, les concepteurs décident de créer un objet draw avec la méthode circle(), square(), rectangle(), elipse(), etc. Les deux fonctions disparaissent et sont remplacées par draw.circle() et draw.square().

Autres conventions

Le versionnage sémantique prévoit également d'autres types de conventions qui utilisent les trois chiffres.

Version alpha

0.0.x

Un logiciel est en version alpha si ses deux premiers chiffres sont 0. Les logiciels en version alpha sont très instables et souvent la rétrocompatibilité n'est pas garantie même si, formellement, on ne change que le chiffre de la correction. De plus, on peut avoir une version en alpha même si le premier chiffre est supérieur à 0, car il s'agit dans ce cas d'une version alpha d'une nouvelle version majeure. La nomenclature sera, dans ce cas, par exemple :

2.0.0-alpha.5

Version beta

0.x.x

Un logiciel est en version beta si son premier chiffre est 0. Les logiciels en version beta sont considérés comme assez proches de la stabilité, mais peuvent présenter encore quelques bugs ou des fonctionnalités incomplètes. Comme pour les versions alpha, il se peut que de nouvelles versions majeures d'un logiciel soient en beta. La nomenclature, dans ce cas, sera par exemple :

4.0.0-beta.9

Long Term Support (LTS)

Une version nommée Long Term Support est une version du logiciel pour laquelle les changements de type correction sont garantis pour une période déterminée (souvent pendant 5 ans). Par exemple si les concepteurs d'un logiciel déterminent que leur version 6.5 est une version LTS, cela signifie qu'ils garantissent des versions :

• 6.5.1
• 6.5.2
• 6.5.3
• ..
• 6.5.n

qui corrigent des bugs ou des problèmes de sécurité jusqu'à la fin de la période indiquée. Une fois cette période terminée, la version est considérée abandonnée, donc aucune correction ni aucun changement mineur ne seront plus apportés. La décision de considérer une version ou une autre en LTS est totalement arbitraire et dépend des concepteurs du logiciel.

Déprécation

Une version, par exemple 1.7.x, est considérée en déprécation si on sait déjà qu'il n'y aura pas de version 1.8.0, et qu'il faudra passer à 2.0.0 (peut-être déjà existante ou en développement actif) pour de nouvelles fonctionnalités.

Autres considérations

Le système de versionnage sémantique, en tant que système conventionnel, n'est pas toujours respecté. Parfois, les développeurs n'y font pas vraiment attention, mais souvent c'est surtout parce qu'il est compliqué de déterminer si une série de changements doit être considérée comme un correctif ou plutôt comme un changement mineur.

De plus, il faut également considérer la perspective adoptée pour pouvoir estimer la nature des changements. Cela peut faire des différences énormes selon que la perspective est celle des utilisateurs ou des développeurs. Si un logiciel change totalement son interface, réorganise complètement l'affichage des informations, mais ne modifie pas -par exemple- la structure de la base de données, cela représente un correctif pour les développeurs de 1.0.0 à 1.0.1, tandis que pour les utilisateurs, cela représenterait plutôt un changement de 1.0.0 à 2.0.0.

Logiciels de gestion de versions

Le versionnage sémantique est soutenu par des logiciels de gestions de versions qui servent, entre autres à :

• Conserver un historique des modifications apportées au code source d’un projet.
• Collaborer efficacement avec d’autres développeurs sur le même projet.
• Gérer les conflits, les erreurs et les bugs dans le code source.
• Distribuer les différentes versions du logiciel aux utilisateurs.

Parmi ces outils clés on retrouve :

1. Git

Git est un système de gestion de versions décentralisé largement utilisé. Il permet à chaque développeur de maintenir une copie complète de l'historique du projet sur son propre système, facilitant le travail hors ligne et la fusion des modifications ultérieures.

1. SVN (Subversion)

SVN (Subversion), en revanche, est un système de gestion de versions centralisé. Contrairement à Git, SVN suit un modèle client-serveur, où chaque utilisateur travaille sur une copie locale du projet et soumet ensuite ses modifications au dépôt central.

Ressources

• Version d'un logiciel (Wikipedia)
• Gestion sémantique de version écrite par Tom Preston-Werner et traduite en français