Dans ce guide, nous allons voir ce que signifie exactement le « Versioning Sémantique ». Ce terme un peu fourre-tout dispose en réalité d’une spécification claire et précise qui permet à tout le monde de se mettre d’accord facilement. Vous pouvez retrouvez cette spécification sur le site suivant : semver.org.

Le versioning sémantique de « Monsieur tout-le-monde »

Si vous demandez à vos collègues informaticiens ce qu’est le versioning sémantique, vous aurez surement droit à cette réponse :

« C’est pas le truc avec major.minor.patch ? »

Et bien, c’est à peu près ça ! Pour faire simple, la principale recommandation du versioning sémantique est celle que tout le monde connaît :

  • Lorsque vous démarrez un nouveau projet, vous attribuez la version 0.0.0 à votre projet.
  • Ensuite dès que vous projet arrive à maturité pour une première livraison, vous passez la version à 1.0.0.

Et étant donné les numéros de version MAJOR.MINOR.PATCH, vous devez suivre les règles suivantes :

  • Le numéro de version majeur est réservé lorsque vous effectuez des modifications de rupture. C’est à dire qu’il n’y a pas de compatibilité entre deux numéros de versions majeurs de l’application.
  • Le numéro de version mineur est utilisé pour ajouter, améliorer ou retirer des fonctionnalités dans votre application (Tout en étant compatible avec la version précédente).
  • Le numéro de patch, que vous utiliserez le plus souvent, et qui correspond au correspond aux corrections de bugs.

Ce système de versioning est dit sémantique car les numéros de versions (et la façon dont ils sont incrémentés) ont une signification particulière.

Par exemple, si vous voyez les numéros de versions 1.x.x et 2.x.x, vous savez que la version 1.x.x précède la version 2.x.x, et que ces deux versions ne sont pas compatibles car il s’agit de versions majeurs.

Comprendre l’origine du versioning sémantique

Tout commence dans le monde de la gestion logicielle, où il existe un lieu redouté appelé l’enfer des dépendances. Plus vous développez votre application, et plus vous ajoutez du code et installez des paquets dans votre logiciel. Jusque là tout va bien. Jusqu’au jour où vous devez livrer une nouvelle version…

  • Si les dépendances de l’application sont trop proches, vous risquez de verrouiller la version (l’incapacité de mettre à niveau un paquet sans devoir lancer de nouvelles versions de chaque paquet dépendant).
  • Si les dépendances sont spécifiées trop espacé, vous aurez de plus en plus de problèmes avec la comptabilité des versions futurs.

Et cela peut virer au cauchemar lorsque que vous ne pouvez plus transférer facilement et en toute sécurité votre projet.

Le versioning sémantique se pose en solution à ce problème, en proposant un ensemble de règles et exigences simples qui dictent comment les numéros de versions doivent être affectés et incrémentés.

Ces règles sont basées sur les pratiques courantes préexistantes utilisées pour le développement de logiciels fermés et open-source :

Les 11 commandements du Versioning Sémantique (que personne ne connaît) 😎

  1. Les logiciels utilisant la version sémantique DOIVENT déclarer une API publique. Cette API pourrait être déclarée dans le code lui-même ou exister dans la documentation. Mais elle doit être faite, être précise et complète.
  2. Un numéro de version normal doit prendre la forme X.Y.Z, où X, Y et Z sont des nombres entiers non négatifs. X est la version principale, Y est la version mineure, et Z est la version de patch. Chaque élément DOIT augmenter numériquement. Par exemple : 1.9.0 -> 1.10.0 -> 1.11.0.
  3. Une fois que votre logiciel a été versionné et publié, le contenu de cette version NE DOIT PLUS être modifié. Toutes les modifications DOIVENT être publiées sous forme de nouvelle version. Simple et efficace.
  4. La version principale zéro (0.y.z) est destinée au développement initial. Tout peut alors changer dans votre code, à n’importe quel moment. L’API publique ne doit pas être considérée comme stable.
  5. La version 1.0.0 définit l’API publique. C’est la version à partir de laquelle vous devez disposé de l’API publique.
  6. La version de patch Z (x.y.Z | x> 0) DOIT être incrémentée si et seulement si des corrections de bugs compatibles avec les versions précédentes sont ajoutées.
  7. La version mineure Y (x.Y.z | x> 0) DOIT être incrémentée si une nouvelle fonctionnalité compatible avec les versions précédentes est introduite dans l’API publique. Elle doit aussi être incrémenté si une fonctionnalité publique de l’API est marquée comme obsolète. Attention, la version de patch DOIT être réinitialisée à 0 lorsque la version mineure est incrémentée ! 😮
  8. La version principale X (X.y.z | X> 0) DOIT être incrémentée si des modifications incompatibles avec les versions précédentes sont introduites dans l’API publique. Cela peut inclure des modifications mineures et de niveau de patch. Logiquement, le patch et la version mineure DOIVENT alors être réinitialisés à 0 lorsque la version majeure est incrémentée.
  9. Une version préliminaire sert à indiquer que la version actuelle est instable et ne peut pas satisfaire aux exigences de compatibilité prévues par la version normale associée. Exemples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92. Quelques précisions sur ces identificateurs présents après le numéro de version :
    1. Les identificateurs DOIVENT comprendre uniquement les alphanumériques ASCII et le trait d’union [0-9A-Za-z-].
    2. Les identificateurs NE DOIVENT PAS être vides.
    3. Les identificateurs numériques NE DOIVENT PAS inclure des zéros en premier.
  1. Les métadonnées de build peuvent être désignées en ajoutant un signe plus et une série d’identificateurs séparés par points, immédiatement après le patch ou la version préliminaire. Ainsi, deux versions qui ne diffèrent que dans les métadonnées de build ont la même priorité. Exemples: 1.0.0-alpha + 001, 1.0.0 + 20130313144700, 1.0.0-beta + exp.sha.5114f85.
    1. Les identificateurs DOIVENT comprendre uniquement les alphanumériques ASCII et le trait d’union [0-9A-Za-z-].
    2. Les identificateurs NE DOIVENT PAS être vides.
    3. Les métadonnées de construction DEVRAIENT être ignorées lors de la détermination de la priorité de la version.
  1. La dernière règle explique comment déterminer l’ordre des numéro de versions. Plutôt qu’un long discours, je vous propose l’exemple suivant : 1.0.0-alpha <1.0.0-alpha.1 <1.0.0-alpha.beta <1.0.0-beta <1.0.0-beta.2 <1.0.0-beta.11 <1.0.0- Rc.1 <1.0.0.

Pourquoi utiliser le versioning sémantique ?

Il n’y a rien de nouveau ou de révolutionnaire. En fait, vous avez probablement déjà fait quelque chose de similaire lorsque vous versionnez vos projets personnels. Mais sans conformité à une spécification formelle, les numéros de version attribués de manière plus ou moins aléatoire deviennent inutiles pour la gestion des dépendances. En donnant un nom et une définition claire  à vos versions grâce aux commandements ci-dessus, il devient facile de communiquer vos intentions aux utilisateurs de votre logiciel !

Si tout cela vous semble souhaitable, tout ce que vous devez faire pour commencer à utiliser le versioning sémantique est de déclarer publiquement (dans votre README par exemple) que vous suivez ces règles, et de vous y tenir par la suite. 😛

 

Pour conclure

Les spécifications du versioning sémantique ont été rédigé par Tom Preston-Werner, inventeur de Gravatars et co-fondateur de GitHub. Autant vous dire qu’il s’agit d’un système qui a fait ses preuves et sur lequel vous pouvez vous appuyer. De plus, c’est ce système de versioning qui est utilisé depuis Angular 2. Je vous explique tout dans ce post.

Pensez au versioning sémantique pour vos prochains développements !

Un commentaire sur « Guide complet du Versioning Sémantique »

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

w

Connexion à %s