Gestion des versions sémantique : qu'est-ce que c'est, qu'est-ce que ce n'est pas et pourquoi vous en avez besoin

La plupart des logiciels que vous utilisez publient souvent de nouvelles versions, généralement identifiées par un numéro de version associé. Le système est appelé « versionnage sémantique » et il vous permet de suivre les progrès du développement. De plus, si vous travaillez avec WordPress, vous pouvez certainement bénéficier de bonnes pratiques de versioning sémantique.

Dans cet article, nous vous donnerons une brève introduction au système de gestion de versions sémantique et à son fonctionnement. Ensuite, nous parlerons de qui peut bénéficier de son utilisation et vous donnerons quelques conseils pour vous assurer de bien faire les choses.

Parlons chiffres !

Qu'est-ce que le contrôle de version sémantique

Si vous allez sur la page de téléchargement de WordPress.org, vous remarquerez qu'elle vous indique quelle version du système de gestion de contenu (CMS) vous téléchargez :

Le système utilisé pour déterminer ce nombre est appelé 'versioning'. Plus précisément, vous regardez un exemple de versionnage sémantique, dans lequel la version est décomposée en trois nombres séparés par des points. Voyons ce que chacune de ces valeurs représente :

• La version principale, qui correspond aux modifications apportées à l'API.
• Mises à jour mineures du logiciel, pas assez importantes pour justifier une mise à jour majeure.
• Correctifs ou corrections de bugs.

Au moment de la rédaction, nous sommes sur la version 5.1.1 de WordPress. La version 5.0.0 est sortie le 6 décembre 2018. Depuis lors, nous avons eu cinq correctifs mineurs (incréments dans le nombre final) et une version mineure, dans cet ordre :

1. 5.0.1
2. 5.0.2
3. 5.0.3
4. 5.0.4
5. 5.1
6. 5.1.1

Comme vous pouvez le voir, le numéro de patch est réinitialisé chaque fois qu'il y a une mise à jour mineure. Il en va de même lorsqu'il y a une version majeure, qui se produit traditionnellement tous les quatre mois en ce qui concerne WordPress.

Tout l'intérêt du versioning sémantique est de vous permettre de suivre tous les changements et les progrès que vous faites. De plus, si vous êtes un utilisateur final et que vous suivez les versions, les numéros de version vous indiquent quand il est vraiment important de mettre à jour. Par exemple, vous pouvez ignorer un correctif de bogue ou deux, mais chaque fois qu'il y a une version mineure ou majeure, vous devez mettre à jour (nous surveillons, vous savez !).

Si vous n'êtes pas sûr que la mise à jour en vaut la peine, consultez simplement le journal des modifications qui accompagne chaque version. Chaque développeur digne de ce nom publiera un compte rendu écrit des nouveautés de chaque version.

Dans l'ensemble, la gestion des versions sémantique est assez simple et est pratique dans de nombreuses situations au-delà du développement logiciel. Parlons de ce que c'est.

Qui peut bénéficier de l'utilisation du contrôle de version sémantique

Habituellement, vous constaterez que ce sont les développeurs qui utilisent des systèmes de gestion de versions. Quant à WordPress, les exemples les plus évidents sont les mises à jour du noyau lui-même. Cependant, les développeurs de plugins et de thèmes utilisent également le versioning sémantique, bien que les chiffres soient souvent difficiles à trouver. Par exemple, si vous consultez une page de plugin sur WordPress.org, vous pouvez trouver des informations sur ses versions et ses journaux de modifications dans l'onglet Développement :

De même, vous pouvez trouver des informations sur le développement d'un thème dans les pages WordPress.org associées. Cependant, dans ces cas, vous devez cliquer sur le lien Development Log en bas de la page :

En bref, vous pouvez utiliser le versioning sémantique pour à peu près n'importe quel type de projet impliquant du code. Cependant, il a également des applications en dehors du développement simple. Par exemple, vous pouvez appliquer la gestion des versions à des projets de conception. Ici, vous pouvez chercher à augmenter le numéro de version pour les changements visuels majeurs, la valeur pour les nouveaux ajouts d'éléments ou les ajustements mineurs. En ce qui concerne les correctifs, vous pouvez les réserver pour de minuscules mises à jour ou corrections visuelles.

Cependant, le versionnage sémantique est peut-être le jeu le plus populaire en ville, mais ce n'est pas le seul système que vous pouvez utiliser. Par exemple, le navigateur Chrome utilise un système de version en quatre sections – major.minor.build.patch .

D'autres projets, comme Ubuntu, utilisent des systèmes construits autour des dates. Par exemple, Ubuntu est actuellement sur la version 19.04, qui, comme vous l'avez peut-être deviné, est sortie en avril 2019.

Dans l'ensemble, il n'existe pas de système de gestion de versions unique qui convienne parfaitement à chaque type de projet. Cependant, le versioning sémantique est une excellente option si vous travaillez dans le développement de logiciels de toute nature. De plus, c'est une excellente introduction si vous n'utilisez pas encore de protocole de gestion des versions.

3 bonnes pratiques pour le contrôle de version sémantique

A présent, vous avez déjà une idée du fonctionnement du versioning sémantique. Cependant, passons en revue quelques conseils pour vous assurer que vous l'utilisez de la bonne façon.

1. Ne commencez pas tout de suite avec la version 1.0

À un moment donné, vous avez probablement utilisé un logiciel qui n'a pas encore atteint la version 1.0. C'est tout à fait normal, puisque les utilisateurs s'attendent à ce que la version 1.0.0 soit relativement stable et sans bogue. Cependant, cela conduit également à des situations où le logiciel met beaucoup de temps à atteindre ce nombre, tout en étant complètement utilisable.

Prenez le jeu PC populaire Dwarf Fortress, par exemple. Il est en cours de développement depuis environ 15 ans et est toujours en version 0.44.12 malgré plus de fonctionnalités que la plupart des jeux majeurs.

Bien que vous puissiez aller à l'extrême avec cela, ne pas commencer tout de suite avec la version 1.0.0 a du sens. Il vous permet de tester la version bêta de votre logiciel et de tempérer les attentes des utilisateurs pendant que vous le faites.

En interne, vous devriez commencer avec la version 0.1.0. Cependant, la plupart des projets ne rendent pas cette version publique, attendant plutôt d'avoir un peu plus de développement à leur actif. En attendant, cependant, vous pouvez utiliser ces versions alpha très limitées pour les tests internes, ce qui est essentiel au développement sain de tout projet.

2. Expliquez les changements spécifiques pour chaque nouvelle version

L'une des situations les plus ennuyeuses que vous puissiez rencontrer en tant qu'utilisateur final est de recevoir une tonne de mises à jour sans savoir ce que font aucune d'entre elles. Nous savons que la plupart des gens ne lisent pas les journaux des modifications, mais si vous envisagez de publier une mise à jour – même s'il ne s'agit que d'un correctif mineur – vous devez la documenter.

Les journaux des modifications, comme leur nom l'indique, sont une simple ventilation des nouveautés de chaque version. Certains développeurs écrivent de longues mises à jour pour expliquer chaque changement et si vous êtes l'un d'entre eux, plus de pouvoir pour vous.

Pour être honnête, nous nous contentons généralement d'une simple liste concise des nouveautés. La création d'un journal des modifications est simple et ne devrait pas prendre longtemps, alors soyez cool et ne lésinez pas sur vos tâches !

3. Recueillez les commentaires des utilisateurs pour chaque version

Vous avez probablement une assez bonne idée de ce à quoi vous voulez que votre projet fini ressemble. Cependant, cela ne signifie pas que vous pouvez vous passer des commentaires des utilisateurs ou du reste de votre équipe.

Idéalement, vous obtiendrez un certain niveau de retour pour chaque version que vous publiez, à l'exception des petits correctifs et des corrections de bugs. L'objectif de ce processus est de vous faire savoir si les utilisateurs rencontrent des problèmes ou ont des problèmes avec la direction que prend le projet.

L'exemple le plus simple de ce processus en action serait de partager la dernière version d'un site Web en cours avec le client. Dans la grande majorité des cas, les clients auront un certain niveau de commentaires pour vous, que vous pourrez intégrer dans les futures versions.

Gardez à l'esprit, cependant, qu'il est important d'écouter les commentaires, mais dans certains cas, vous en savez peut-être mieux que vos utilisateurs. Cependant, cela ne signifie pas que vous devez les ignorer, mais parfois votre instinct peut avoir raison.

Conclusion

Le versioning sémantique est un système remarquablement simple. Avec seulement quelques chiffres, vous pouvez transmettre de nombreuses informations sur l'avancement du développement de votre projet, informer les utilisateurs lorsqu'il y a de nouvelles mises à jour importantes et généralement garder les choses organisées.

Récapitulons trois des meilleures pratiques que vous devez garder à l'esprit pour le contrôle de version sémantique :

1. Ne commencez pas avec la première version de la porte.
2. Expliquez les changements spécifiques pour chaque nouvelle version.
3. Recueillez les commentaires des utilisateurs pour chaque version.

Vous avez des questions sur l'utilisation du versioning sémantique ? Demandez dans la section commentaires ci-dessous!

Image miniature de l'article par fatmawati achmad zaenuri / shutterstock.com