Le versionning de vos applications : Sémantique SemVer

Le versioning des applications est un élément intégré essentiellement dans le paysage digital, que ce soit pour les smartphones, les jeux vidéo ou les plugins. Cependant, la structuration et la sélection des numéros de versions demeurent floues pour la plupart d’entre nous.

‍

Cet article vise à présenter la sémantique la plus répandue : SemVer (pour Semantic Versioning). Ses avantages sont multiples :

‍

Organisation de l’équipe de développement

L’équipe de développement découpe les différentes versions de l’application, principalement à travers son action sur le référentiel GIT du projet, fonctionnant par des tags pour les mises en production. Notons d’ailleurs que la majorité des ressources de projets publics proviennent de Github. La sémantique confère également un sens au code, permettant aux développeurs (et aux intervenants ultérieurs) de comprendre si des changements majeurs ou mineurs ont été effectués.

‍

Organisation et communication au sein de l’équipe projet

Plus un projet est constitué de fonctionnalités majeures, avec une évolutivité importante dans le temps, plus il est difficile de déterminer l’étendue des tâches à effectuer : récapitulatifs, recettes, déploiements, etc. Du côté marketing, le renouvellement des versions permet de susciter un sentiment de nouveauté (notamment sur les smartphones) chez les clients ou visiteurs avant même qu’ils en prennent connaissance, ce qui augmente l’affluence sur le produit ou l’application.

SemVer :

Parmi la multitude de sémantiques existantes, la plus utilisée est SemVer. Elle utilise un numéro de version en trois parties : Majeur.Mineur.Correction (par exemple 1.2.3 ou 1.4.15). Il existe un certain nombre de conventions, notamment :

• Les numéros de version doivent être des entiers positifs.
• Si le premier nombre à gauche (Majeur) n’est pas supérieur à 1, le projet est encore en phase de bêta, la première mise en production conduira donc à la version 1.0.0.
• Chaque changement en production doit entraîner une itération en fonction de l’importance des changements.
• Pour en savoir plus : https://semver.org/spec/v2.0.0.html

Maintenant que les règles de dénomination sont connues, il reste à déterminer l’importance des modifications. SemVer fournit également des indications, bien que très génériques, car tout dépend de l’architecture de votre application :

• Majeur : Changements rétrocompatibles (par exemple : Framework, Design ; etc.), changements de noms de fonctions sur une API.
• Mineur : Ajouts/Modifications de fonctionnalités rétrocompatibles. Exemple : Ajout d’un nouveau champ sur une API.
• Correction : Comme son nom l’indique, on l’incrémente pour une correction/dépannage d’anomalie(s).

Ainsi, vous en savez un peu plus (et moi aussi !) sur l’articulation des numéros de version.

Bien que ces choix restent totalement subjectifs, chacun est libre de choisir, le but étant d’être clair au niveau des équipes de développement, de projet ET avec le ou les clients sur le contenu de chaque nouvelle version. Enfin, je vous invite à consulter la documentation officielle pour en apprendre davantage : https://semver.org/.

‍