Salut, c'est Nicolas Brondin Bernhardt et bienvenue dans ce nouvel épisode du podcast de Code Garage.
Aujourd'hui, on va parler du Semi-Antique Versioning.
Je pense qu'il vous est déjà arrivé de commencer un projet et de lui attribuer un numéro de version,
on va dire 0.0.1, et de pas savoir comment le faire évoluer par la suite.
On est habitué à voir passer beaucoup de mises à jour logiciels,
mais en réalité, ça signifie quoi la mise à jour d'une dépendance de la version 15.1.3 à la version 15.2.1 ?
Ça veut dire quoi ces chiffres ?
Et est-ce qu'ils sont choisis un peu arbitrairement ?
Ou est-ce qu'ils ont vraiment une signification particulière ?
Justement, bienvenue dans le monde du Semi-Antique Versioning, qu'on appelle aussi SEMVERT tout simplement, et de ses bonnes pratiques.
Donc l'objectif du Semi-Antique Versioning, c'est de donner un numéro unique à chaque nouvelle version d'un logiciel.
Évidemment, c'est logiciel au sens large.
Ça peut être une dépendance en JavaScript, ça peut être une application mobile, ça peut être une librairie, ça peut être peu importe.
Et l'idée, c'est de pouvoir identifier cette nouvelle version tout en apportant un maximum d'informations à l'utilisateur sur ces évolutions.
Donc, un identifiant minimal, on va dire, le minimum requis, ça va ressembler à par exemple 0.0.1.
Parce que tout simplement, on dira plutôt que c'est MAJOR.MINOR.PATCH.
Ok ? On a trois chiffres.
Un chiffre qui représente la version majeure, un chiffre qui représente la version mineure et un chiffre qui représente la version de patch.
Alors, MAJOR, d'abord, c'est le plus critique.
C'est le seul qui indique une évolution de l'API tellement importante que la rétro-compatibilité n'est plus assurée.
Ça indique donc que cette version ne sera pas forcément compatible avec les versions précédentes.
Dans certains modes de développement logiciel, ça voulait également dire que le binaire, tout simplement, on ne pouvait pas simplement remplacer le binaire
d'une dépendance d'une version à une autre parce que la compilation ne fonctionnerait plus.
Ensuite, la version mineure, ce chiffre, ça permet tout simplement d'indiquer que des fonctionnalités ont été ajoutées.
Ou alors aussi que des fonctionnalités ont été dépréciées, mais que toute la paix reste compatible avec les anciennes versions.
Et enfin, la version de patch, ça indique simplement que des bugs ont été corrigés, mais que toute la rétro-compatibilité est complètement assurée.
Alors, il est aussi possible d'ajouter des informations supplémentaires au code de la version en ajoutant, par exemple, des identifieurs pour identifier la version actuelle
comme étant une release ou une pré-release, par exemple.
Donc, pour des identifiant beaucoup plus caractéristiques, on pourra écrire par exemple, 10, donc version majeure 10, 0.3, version mineure 3, 0.6, la version de patch,
tirer RC pour release candidate.
Donc, en gros, c'est normalement cette version-là qui sortira en tant qu'release, mais elle doit encore être testée.
Mais on pourra aussi trouver des identifiant comme identifiant plutôt, comme alpha ou beta, toujours séparé par un tiré.
Après, le numéro de version.
Et il y a même d'autres métadonnées qui peuvent être ajoutées, comme le numéro de build interne, par exemple.
Et ces numéros, ils devront toujours être précédés du signe plus, du coup.
Donc, ça peut donner par exemple 10.3.6 tiré RC plus 1452, c'est le numéro de build numéro 1452.
Voilà, quand on a encore besoin de plus de précision pour identifier une version très très très précisément.
Alors, il y a quelques règles à connaître dans le Semi-Tik Versioning.
Donc, il y en a 11 précisément à suivre dans la spécification de la version 2.0.0 du Semi-Tik Versioning.
Je ne vais pas toutes vous les lister, parce que il y en a qui sont un peu plus, c'est un peu plus des détails que d'autres.
Mais moi, j'en ai pris 3 qui me paraissent vraiment importantes.
D'abord, la première, c'est que les chiffres donc major, minor et patch doivent toujours être des entiers positifs,
supérieurs ou égaux à 0.
Et en plus, ils doivent pas contenir ce qu'on appelle le 0 antédéposé.
Non, antéposé, pardon.
Donc, par exemple, on ne peut pas dire 10.01, ok ?
On ne peut pas mettre de 0 ou 10.046.
Ça sera 10.1 ou 10.46.
Voilà, il n'y aura jamais de 0 avant qui ne sert à rien, on va dire, plus ou moins.
Ensuite, un chiffre majeur à 0, ça indique un développement initial.
Et donc, c'est un petit peu le cas particulier où tant que le chiffre majeur est à 0,
l'API peut changer à tout moment sans être reflété dans le numéro de version.
Voilà, donc vous pouvez rester en numéro 0.0.1,
tant que c'est en développement que votre projet n'a pas été déployé nulle part, etc.
L'API ne doit pas être considéré comme étant stable tant qu'on a un numéro majeur à 0.
Si jamais le chiffre, donc ça, c'est la troisième règle,
si le chiffre majeur est incrementé,
minor et patch doivent aussi être remis à 0.
Et c'est pareil pour patch si c'est minor qu'incrémenté, ok ?
Mais donc vous êtes en 1.3.6,
si vous passez en version mineure 1.4,
vous n'allez pas passer en 1.4.6,
vous allez forcément repasser en 1.4.0.
Voilà, donc à noter que les chiffres doivent toujours être incrémentés,
mais ils ne doivent pas forcément être linéaires.
Il est possible, par exemple, de passer de la version 1.3.0 à la version 1.5.0, ok ?
Ça peut indiquer, par exemple, que de nombreuses fonctionnalités ont été ajoutées,
et donc ça donne encore un petit peu plus de sens justement à ce versionnit.
Moi, je vous invite quand même à lire la spécification de SEMVER,
du coup, qui est disponible, je vous mets le lien directement dans les notes de l'épisode,
parce que honnêtement, la spécification est très bien écrite, elle est accessible,
et vous pouvez même y trouver une FAQ avec les réponses aux questions
pour vous guider, on va dire, dans vos décisions et dans vos choix.
Pour conclure, un petit peu comme c'est expliqué dans la spécification,
le SEMENTIC versioning, ce n'est pas une idée révolutionnaire,
et vous optez sûrement déjà pour une convention personnelle qui est plus ou moins proche,
qui est un peu logique, mais l'utilisation stricte de SEMVER est indispensable,
vraiment pour une gestion des dépendances fonctionnelles et robustes,
sinon on se retrouve avec des problèmes, et quand on a un problème sur une sous-dépendance,
d'une sous-dépendance, d'une sous-dépendance, juste à cause d'une montée de version,
ou d'un changement de version, ça peut casser énormément de logiciels qui sont basés dessus,
et donc il faut faire très attention à ça.
J'espère que vous aurez appris des choses avec cet épisode du podcast,
moi je vous donne rendez-vous sur Code Garage,
Code Garage, qu'est-ce que c'est ? C'est une plateforme de formation pour tous les devs
et toutes les développeuses qui veulent continuer à se former en continu,
donc vous avez accès à tous les cours en illimité, les projets, les exercices,
pour 19,99€ par mois, et sinon je vous dis à la semaine prochaine pour un nouvel épisode du podcast.
Ciao !