Image fusée

Comprendre le versioning de vos applications

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
Maintenant que vous connaissez les règles du nommage, il reste à savoir comment définir l'importance de nos modifications. SemVer donne également des éléments de réponse, très générique car tous dépend de l'articulation de votre application:
  • 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)
Voilà ! Vous en savez un peu plus (et moi aussi !) sur l'articulation des numéros de version, bien que ces choix restent totalement subjectifs, libre à chacun de choisir, le but étant d'être clair au niveau des équipes de développements, de projet ET avec le ou les clients sur le contenu de chaque nouvelle release. Enfin, je vous renvoie à la documentation officielle pour en apprendre plus :https://semver.org/
11/06/2019
Image auteur
Jeffrey Meyus
Développeur Back

Laissez nous un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous aimerez aussi ...

Icone fusée

Démarrez votre projet digital !

Je me lance