Le versioning des applications est quasi intégré dans le paysage digital que ce soit sur les versions des smarphones, de jeux vidéos ou des plugins. Cependant, la structure et le choix de ces numéros de versions restent floues pour la plupart d’entre nous.
Le but de l’article est de vous présenter la sémantique la plus connue : SemVer !
Les intérêts …
Les avantages de bien définir la sémantique de vos versions sont nombreuses mais les plus importantes sont :
- L’organisation de l’équipe de développement
En effet, ce sont eux qui vont découper les différentes versions de l’application, principalement via leurs action sur le repository GIT du projet qui fonctionnent par tags pour les mises en production. D'ailleurs comme vous pouvez le voir, la majorité des ressources de projets publiques provient de Github .
La sémantique transmet également un sens au code, c’es à dire que seulement via un ensemble de numéros, les différents développeurs (et ceux qui s’y grefferont) comprendront si des changements majeurs ou mineurs ont été effectués.
- L’organisation et la communication de l’équipe projet
Plus un projet est composé de fonctionnalisés majeures, couplé à une évolutivité importante dans le temps, plus il est difficile de savoir le scope des tâches à effectuer : récapitulatifs, recettes, déploiements, etc …
Côté marketing, l’intérêt de renouveler les versions permet de partager un sentiment de nouveautés (notamment sur les smartphones) au client / visiteur avant même que ces derniers en prennent connaissance. Cela augmente par conséquent l’affluence sur le produit ou l’application.
SemVer !
Comme évoqué plus haut, ils existent une multitude de sémantiques mais la plus utilisé se nomme : SemVer
Elle utilise un numéro de version en 3 parties : Major.Minor.Patch (1.2.3 / 1.4.15)
Ils existent un certains nombres de conventions dont :
- La valeur des numéros doit être entier et positif
- Il faut considérer que si le premier nombre à gauche (Major) n’est pas supérieur à 1 alors c’est que le projet est encore en phase de bêta, par conséquent la première mise en production conduira à la version 1.0.0
- Il faut itérer à chaque changement en production en fonction de l'importance des changements
- Si vous voulez en découvrir plus : https://semver.org/spec/v2.0.0.html
- Major : Changements rétro incompatibles (Ex : Framework, Design; etc..), changements de noms de fonctions sur une API,
- Minor : Ajouts / Modifications de fonctionnalités rétro compatibles. Exemple : Renvoie d'un nouveau champ sur une API
- Patch : Son libellé parle pour lui, on l'incrémente sur une correction / fix d'anomalie(s)