Introduction à  la gestion sémantique des versions de logiciels

Article posté le 05-03-2014 dans la catégorie Développement

Article mis à jour le : 05-05-2022

Explication des bases du semantic versioning: quel système de version utiliser

La gestion sémantique de versions, aussi appelée gestion de numéros de versions - ou semantic versioning ou encore SemVer -, est un procédé qui permet d'attribuer un numéro unique à une version de l'application.

La règle de base à comprendre est que chaque version publiée de l'application possède un numéro unique. Si vous faites ne serait-ce qu'une seule modification, vous devez lui attribuer un nouveau numéro. On appelle cela le "versioning", bien qu'aujourd'hui on utilise généralement le "versioning étendu". 

1- Le modèle utilisé

Le versioning étendu utilise un modèle X.Y.Z :

• X : Version Majeure du logiciel
• Y : Version mineure du logiciel
• Z : Révision de la version précédente

Version majeure

Exemple : Version 1.Y, 2.Y etc.

Il s'agit d'une profonde modification d'une application ou d'un API, notamment l'ajout/modification/suppression de fonctionnalités importantes. Dans le cas d'un API, il s'agit de modifications qui le rendent incompatible avec la version précédente.

Version mineure

Exemple : Version X.1, X.2 etc.

Il s'agit de modification mineure. L'ajout/modification de fonctions secondaires. Dans le cadre d'un API, celui-ci reste compatible avec la version précédente.

Révision

Exemple : Version X.Y.1, X.Y.3

Dans ce cas il s'agit de corrections de bugs de la version précédente.

2- Quelques règles

Le développement et la programmation sont des processus scientifiques qui requièrent rigueur et discipline. Si vous souhaitez que tout se passe bien et ne devienne pas un cauchemar au fur et à mesure que votre application grandit, que vous utilisez des dépendances ou publiez des API, voici quelques règles a respecter :

• Ne jamais utiliser de nombres négatifs ou à virgule
• Toujours créer et mettre à jour une documentation précise. Pensez aux développeurs qui passeront après vous... ou aux développeurs tiers qui veulent utiliser vos APIs.
• Ne jamais modifier un contenu après une publication de version (release). Toujours publier une nouvelle version à chaque modification de la précédente. Exemple: vous faites une mise à jour X.2.0, dans laquelle vous rajouter/modifier pleins de modifications. Vous vous rendez compte après publication qu'il y a un bug. Pour le corriger, vous modifiez mais passez en X.2.1
• Le premier nombre ne doit pas être zéro. Le zéro est toujours utilisé durant les périodes de développement, avant la publication de la 1.0 ou de la 2.0...
• Si vous faites des modifications tous les jours, cela veut dire que vous êtes en développement (ou alors c'est mauvais signe), vous êtes donc en 0.Y.Z.
• Dans le cas d'une version de pré-livraison (pre-release), vous pouvez anoter la version avec une série d'identifiants alphanumériques et de traits-d'unions. Ces identifiants ne doivent pas être vide. Les identifiants doivent être précédés d'un trait d'union pour les séparer du reste du numéro de version. Exemple : 0.4.3-alpha

3- Le cycle de vie de l'application

Concernant le cycle de vie de votre développement et notamment les versions de pre-release, voici l'essentiel à retenir :

• X.Y.Z-dev : version interne à l'équipe de développement
• X.Y.Z-alpha : il s'agit d'une version fonctionnelle mais ne comportant pas toutes les fonctions et pouvant comporter des bugs. Il s'agit bien souvent d'une version utilisée comme preuve de faisabilité (ou POC pour "Proof of concept"), pour valider le fonctionnement général avec votre client
• X.Y.Z-beta : Version presque complète mais comportant certainement des bugs ou des améliorations à apporter. Ici commencent généralement les tests en condition réelle.
• X.Y.Z-rc.x : RC pour "Release Candidate". Il s'agit d'une version complète mais pouvant comporter des bugs. Il y a souvent plusieurs RC avant d'obtenir la version finale ("final")
• X.Y.Z-final : Comme son nom l'indique, la version est terminée et utilisable en mode production.