Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/06856.jsonl.gz/1375

Versionnage sémantique
Sommaire
1 Introduction
Le vérsionnage sémantique (de l'anglais semantic versioning) ou gestion sémantique de version est un système conventionnel d'indiquer la version d'un logiciel, d'un plugin, d'une bibliothèque ou autre élément technologique avec trois numéros allant de 0 à infini séparés par un point.
12.345.678
Chacun de ce chiffre est associé à un type de changement par rapport à la version précédente. Dans l'ordre :
- Le premier chiffre représente une modification majeure
- Le deuxième chiffre représente une modification mineure
- Le troisième chiffre 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 plugin ou bibliothèques) pour fonctionner. Par exemple un site web peut marcher correctement seulement à partir d'une certaine version d'un navigateur web. En ce cas, donc, le site dépend de la version du navigateur web.
2 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.
2.1 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 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.
2.2 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és respectent la rétrocompatibilité MAIS une ou plusieurs fonctionnalités ont été ajoutées. Veuillez noter que lorsqu'on augmente la version mineur, le chiffre de correction redémarre à 0. Les changements mineurs sont assez fréquents, car ils apportent souvent des corrections à des requêtes des utilisateurs pour des 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é horizontal, tout en gardant la version verticale intacte et comme choix prédéfinie
- Etc.
2.3 Version majeure
de 1.x.x à 2.0.0
On augmente le chiffre de la version majeur 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 à une 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(). Pour 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().
3 Autres conventions
Le versionnage sémantique prévoit également d'autres types de conventions qui utilisent les trois chiffres.
3.1 Version alpha
0.0.x
Un logiciel est en version alpha si ces 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 des versions en alpha même si le premier chiffre et supérieur à 0, car il s'agit dans ces cas d'une version alpha d'une nouvelle version majeur. La nomenclature sera dans ce cas par exemple :
2.0.0-alpha.5
3.2 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 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 des nouvelles versions majeures d'un logiciel soient en beta. La nomenclature sera dans ce cas par exemple :
4.0.0-beta.9
3.3 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 leur version 6.5 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 quelle version considérer en LTS est totalement arbitraire et dépend des concepteurs du logiciel.
3.4 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 une version 1.8.0, et il faudra passer à 2.0.0 (peut-être déjà existante ou en développement actif) pour des nouvelles fonctionnalités.
4 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 plutôt parce qu'il est compliqué de déterminer si une série de changements peut être considérée un correctif ou un changement mineur.
De plus, il faut considérer également la perspective adoptée pour considérer les changements. Cela peut faire des différences énormes si la perspective est celle des utilisateurs ou celles 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 des données, pour les développeurs cela représente un correctif 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.