Gestion sémantique des versions sans API publique

Qu’est-ce que SemVer ?

SemVer est un anglicisme utilisé en informatique pour « Semantic Versioning », soit « Gestion sémantique des versions » en français. Il s’agit d’un système de notation à trois nombre désignant chacun une évolution : majeur.mineur.correctif. De cette manière, lorsque la version change, il est facile de comprendre le type d’évolution : un changement majeur ou un simple correctif de bug par exemple. Dans le détail :

• majeur correspond à des modifications non rétrocompatibles
• mineur correspond à des modifications rétrocompatibles
• correctif correspond aux modifications n’affectant pas l’API

Ce système de gestion des versions est conçu pour le développement de logiciels, et plus largement, d’applications possédant une API publique. Il a été écrit par Tom Preston-Werner, le cofondateur de Github et l’inventeur de Gravatars. Le site de SemVer explique comment procéder pour changer les numéro de versions. Il donne quelques astuces pour s’assurer que les versions sont correctement incrémentées. Bref, la documentation est bien détaillée pour ce type de projet.

SemVer sans API publique, est-ce possible ?

En s’arrêtant là, SemVer est un bon moyen de gérer ses versions de manière compréhensible par tout le monde (d’où le mot « sémantique »). Seulement, il n’est pas conçu pour être utilisé avec des projets ne possédant pas d’API. Prenons l’exemple d’un thème. Si, nous suivons la logique SemVer, peu importe la modification apportée au thème, le seul numéro à incrémenter est correctif. Vous pouvez donc vous retrouverez avec un numéro de version ressemblant à 0.0.86. Est-ce vraiment parlant ? De mon point de vue, nous perdons l’aspect sémantique.

Certains diront que SemVer ne doit pas être utilisé pour un tel projet. Pourtant, avec VS Code, un thème doit utiliser le format SemVer pour ses versions. Par conséquent, je ne respecte pas SemVer à la lettre ; je l’adapte à mon projet. Je ne sais pas si c’est une bonne pratique, mais cela me semble plus parlant lorsque ce projet ne possède pas d’API. Ainsi, ce qui suit n’engage que moi, mais de cette manière vous comprendrez comment je gère les versions de Coldark.

Ma gestion de SemVer sans API publique

Comment je procède ?

Lorsqu’un thème est prêt à être rendu public, j’incrémente le numéro de version majeur, soit 1.0.0. Ce numéro ne devrait plus changer par la suite. Lorsque j’apporte une modification importante au niveau de l’interface (un changement de couleurs par exemple) ou si je change le lien du dépôt, il me semble que mineur doit être utilisé, ce qui ressemble donc à 1.1.0. Enfin, si je corrige un bug ou si je fais un ajustement qui ne change pas réellement l’apparence du thème, j’incrémente correctif, soit 1.1.1. Même en suivant ce principe, ce n’est pas toujours évident de savoir s’il faut incrémenter mineur ou correctif.

Les limites

Déjà, le changement d’apparence « peu important » est assez subjectif. Pour ma part, si le rendu reste similaire, j’incrémente correctif. Si j’utilise une autre couleur et que le changement est réellement visible, j’incrémente plutôt mineur.

Ensuite, est-ce que l’ajout d’un nouveau paramètre est un changement mineur ou un simple correctif ? Là encore, je dirais ça dépend. Si ce nouveau paramètre ne change pas significativement l’aspect visuel du thème, il me semble que correctif convient. Si plusieurs paramètres sont ajoutés en même temps et que le changement semble significatif, j’incrémente plutôt mineur.

Et avant de publier le thème ?

Enfin, entre 0.0.1 et 1.0.0, je dois reconnaître que je ne sais pas vraiment comment utiliser SemVer. Étant donné que je suis la seule personne à contribuer à Coldark (entre autres), je ne me pose pas plus la question que ça. Entre 0.0.1 et 1.0.0, je créé plusieurs commits mais je n’incrémente jamais la version… Je ne pense pas que ce soit une bonne idée en équipe, mais vu que le thème n’est pas encore prêt et évolue sans arrêt, j’ai un peu de mal à voir quel numéro de version incrémenter. Il ne s’agit pas d’un correctif puisque le thème est en cours de création… À la limite, un changement mineur pourrait s’appliquer. Cependant, dans ce cas-là, cela reviendrait au problème de départ (avec un cran d’écart) ; nous passerions de 0.0.1 à 0.1.0 puis 0.2.0, 0.3.0, etc. En procédant ainsi, nous perdons l’aspect sémantique je pense… Ceci dit, il s’agit de la recommandation de SemVer :

Comment dois-je gérer les révisions dans la phase initiale de développement 0.y.z ?

La chose la plus simple à faire est de commencer vos développements avec une version initiale à 0.1.0 puis d’incrémenter l’identifiant de version mineure pour chaque nouvelle publication.

Source : https://semver.org/lang/fr/#faq

Épilogue

Bref, vous l’aurez compris, SemVer est conçu pour des projets possédant une API publique. Si vous souhaitez l’utiliser ailleurs, la gestion des versions n’est pas aussi simple.

Pour ma part, même si j’essaie d’appliquer SemVer à certains projets qui ne sont pas conçus pour, ma gestion reste un peu aléatoire. Je ne pense pas qu’il y ait vraiment de bonnes pratiques dans ces cas là. Il s’agira plutôt d’une entente au sein de l’équipe de développement sur la manière de gérer les versions.