Qu’est-ce que le versionnage sémantique? –

Le versionnage sémantique est une convention formelle pour déterminer le numéro de version des nouvelles versions de logiciels. La norme aide les utilisateurs de logiciels à comprendre la gravité des changements dans chaque nouvelle distribution.

Un projet qui utilise le versionnage sémantique annoncera un Majeur, Mineur et Pièce numéro pour chaque version. La chaîne de version 1.2.3 indique un Majeur version de 1, a mineur version de 2 et un numéro de patch de 3.

Les numéros de version utilisant ce format sont largement utilisés par les progiciels et les exécutables des utilisateurs finaux tels que les applications et les jeux. Tous les projets ne suivent pas exactement la norme définie par semver.org.

La spécification a été créée pour résoudre les problèmes causés par des pratiques de gestion des versions incohérentes parmi les progiciels utilisés comme dépendances. Par «package» et «dépendance», nous faisons référence à une bibliothèque de code destinée à être utilisée dans un autre projet logiciel et distribuée par un gestionnaire de packages tel que npm, composer ou nuget. C’est l’application du versionnage sémantique que nous envisageons dans cet article.

Majeur, mineur et patch

Il est important de comprendre la signification des trois éléments impliqués. Ensemble, ils tracent le parcours de développement d’un projet et relient l’impact de chaque nouvelle version sur l’utilisateur final.

• Numéro majeur – Le nombre majeur indique la version actuelle de l’interface publique du package. Cela devrait être incrémenté chaque fois que vous apportez une modification qui obligerait les utilisateurs existants de votre package à mettre à jour leur propre travail.
• Numéro mineur – Le chiffre mineur décrit la version fonctionnelle actuelle de votre logiciel. Ceci est incrémenté chaque fois que vous ajoutez une nouvelle fonctionnalité, mais ne modifiez pas autrement l’interface de votre package. Il communique aux utilisateurs qu’un changement important a été effectué mais que le package reste entièrement rétrocompatible avec le numéro mineur précédent.
• Numéro de patch – Le numéro de correctif est incrémenté chaque fois que vous effectuez une modification mineure qui n’affecte ni l’interface publique ni la fonctionnalité globale de votre package. Ceci est le plus couramment utilisé pour les corrections de bogues. Les consommateurs devraient toujours pouvoir mettre à jour la dernière version du correctif sans hésitation.

La structure de version du contrôle de version sémantique est mieux modélisée sous forme d’arbre. En haut, vous avez les modifications de votre interface publique, chacune entraînant un nouveau nombre majeur. Chaque série majeure a son propre ensemble de versions mineures, où de nouvelles fonctionnalités sont ajoutées d’une manière rétrocompatible. Enfin, les versions mineures peuvent recevoir des correctifs de correction de bogues de temps en temps.

Où commencer?

La plupart des projets devraient utiliser 1.0.0 comme leur version initiale. Vous publiez votre première interface publique et un ensemble initial de fonctionnalités inchangé. Vous n’avez pas encore eu à créer de patch, donc la version du patch est 0.

Voyons maintenant ce qui se passe lorsque vous modifiez votre package. Après votre première version, vous recevez un rapport de bogue d’un utilisateur. Lorsque vous publiez le correctif, le numéro de version correct sera 1.0.1. Si vous deviez ensuite créer une autre version de correction de bogue, vous augmenteriez le numéro de patch à 1.0.2.

En attendant, vous avez également travaillé sur une nouvelle fonctionnalité passionnante. C’est entièrement facultatif afin que les utilisateurs n’aient rien à faire pour mettre à niveau. Vous libérez ceci comme 1.1.0 – une nouvelle série fonctionnelle a été créée et vous n’avez pas encore eu à la patcher. Malheureusement, les rapports de bogues arrivent bientôt et ainsi 1.1.1 est poussé vers vos utilisateurs.

Plusieurs mois plus tard, vous avez décidé de refactoriser l’ensemble du projet. Certaines des fonctionnalités que vous offriez ont été supprimées ou sont désormais accessibles via une interface consolidée. Si vous publiez ce travail, les personnes utilisant la version actuelle de votre package devront apporter des modifications majeures à leur projet. Il est temps pour vous de publier 2.0.0 dans votre référentiel de packages.

Maintenir les anciennes succursales

Le fait de déplacer un nombre dans votre chaîne de version ne crée pas de point de non-retour. Après publication 1.1.1, vous pourriez découvrir un bogue qui était également présent dans 1.0.2. En utilisant des branches dans votre système de contrôle de source, vous pouvez appliquer le correctif aux deux séries de versions. Vous finiriez par relâcher 1.1.2 et 1.0.3.

De même, vous souhaiterez peut-être continuer à maintenir le 1.x branche de votre projet malgré la publication 2.0.0. Cela peut sembler étrange de publier 1.1.2 après 2.0.1 mais c’est une pratique parfaitement acceptable. Le contrôle de version sémantique ne crée pas un numéro de version linéaire toujours incrémenté; au lieu de cela, il est destiné à être utilisé dans le cadre d’un modèle de développement de branchement qui capitalise sur la facilité de correction offerte par les systèmes de contrôle de source tels que Git.

Les versions publiées doivent être immuables. Une fois que vous avez créé une version, telle que 2.4.3, vous ne pouvez pas le «mettre à jour» en poussant simplement du code supplémentaire sous la même chaîne de version. Vous devez attribuer un nouveau numéro de version à chaque version, afin que les utilisateurs puissent toujours accéder à chaque révision spécifique de votre package.

Gestion des packages de pré-version

Normalement, vous bosse toujours la version principale de votre projet chaque fois qu’une modification incompatible avec les versions antérieures est introduite. Lorsque vous êtes dans un état de pré-lancement, votre base de code peut évoluer très rapidement, ce qui entraîne la publication d’un grand nombre de versions majeures.

Vous pouvez éviter cela en annonçant votre projet comme 0.y.z pour commencer. Adopter 0 car votre version principale indique que votre package est instable. Les règles normales concernant les modifications incompatibles avec les versions antérieures ne s’appliquent plus, vous pouvez donc publier de nouvelles versions en incrémentant uniquement les numéros mineurs et de correctif. Cela signifie que vous pouvez toujours utiliser 1.0.0 pour étiqueter la première version «terminée» de votre logiciel.

Vous pouvez également ajouter des «identificateurs» supplémentaires à la fin de la chaîne de version, en utilisant un trait d’union comme séparateur: 1.0.0-alpha.1. Vous pouvez l’utiliser pour désigner clairement les variantes alpha et bêta. De même, vous pouvez inclure des métadonnées de build en les ajoutant avec le + personnage: 1.1.0-alpha.1+linux_x86.

Conclusion

L’utilisation cohérente du contrôle de version sémantique aide les utilisateurs à avoir confiance en votre projet. Ils peuvent clairement voir comment votre base de code évolue et s’ils devront travailler eux-mêmes pour rester à jour.

La publicité d’une chaîne de version sémantique est essentielle lorsque vous publiez sur les gestionnaires de packages les plus courants. Néanmoins, c’est en fin de compte votre décision des numéros que vous augmentez pour chaque nouvelle version. Le respect de la norme communique clairement vos intentions à la communauté et minimise le risque d’interrompre involontairement le travail de quelqu’un d’autre.