Photo de Ross Findon sur Unsplash

Récemment, j’ai écrit un article sur les choses que les développeurs disent et ce qu’ils veulent dire. J’ai eu beaucoup de plaisir à l’écrire et j’ai apprécié les commentaires que le post a générés. Il y a beaucoup plus de choses sur lesquelles je voulais écrire et je prévois de faire un post de suivi à l’avenir avec plus de choses, mais il y avait un peu de jargon qui méritait plus qu’une seule explication de paragraphe: Semver.

Qu’est-ce que Semver ? Semver est l’abréviation de semantic versioning. Le versionnage sémantique est un moyen standardisé de donner du sens à vos versions logicielles. C’est un moyen pour les auteurs de logiciels de communiquer succinctement aux consommateurs de leurs logiciels des informations importantes qu’ils devraient connaître à propos de cette version.

Semver est représenté par seulement trois nombres séparés par des points. Par exemple, la version actuelle de lodash, à la date de publication de cet article, est 4.17.11, que vous pouvez trouver sur leur page de profil github ou npm. Avec ce numéro, je peux facilement indiquer toutes les informations de compatibilité dont j’ai besoin et décider si je dois passer à la dernière révision et combien de travail cela peut prendre pour le faire.

Chaque numéro correspond à un niveau de révision différent, en fonction de ce qui a été modifié dans la révision. Lire de gauche à droite pour écrire le nombre représente la version majeure actuelle, la version mineure actuelle de la version majeure actuelle et la version de correctif actuelle de la version mineure actuelle (Majeure.Mineur.Patch). En utilisant l’exemple de Lodash ci-dessus, 4.17.11 signifie le 11ème patch depuis la 17ème version mineure, depuis la 4ème version majeure. Lorsqu’un nombre est augmenté, tous les nombres à droite recommencent à zéro.

Une version de correctif est utilisée pour signifier que les modifications de code de cette révision n’ont pas ajouté de nouvelles fonctionnalités ou modifications de l’API et sont rétrocompatibles avec la version précédente. Il est généralement utilisé pour signifier une correction de bogue. La chose la plus importante à savoir est que le code n’a pas changé la façon dont il est utilisé. En utilisant l’exemple de lodash ci-dessus, si une nouvelle révision de correctif est envoyée, la version serait 4.17.12

Mineur

Une version mineure est utilisée pour signifier que la fonctionnalité a été ajoutée, mais le code est par ailleurs rétrocompatible. Conformément à l’exemple de lodash, si une nouvelle fonction est ajoutée ou un nouveau paramètre facultatif est ajouté à une fonction existante, la version serait 4.18.0. La chose la plus importante à retenir est que cette fonctionnalité ajoutée est facultative et que la mise à niveau vers cette version ne devrait pas nécessiter de modifications de code de la part de l’utilisateur

Major

Lorsque vous apportez des modifications à l’API publique et que le code n’est plus rétrocompatible, vous avez apporté des modifications « cassantes ». Cela nécessite une augmentation de révision majeure. Cela peut signifier qu’une fonctionnalité a été supprimée ou qu’une fonctionnalité a été modifiée, ce qui oblige l’utilisateur à apporter des modifications au code pour accepter la mise à jour. En utilisant le même exemple, une version majeure serait par 5.0.0

Pré-version

Les choses sont légèrement différentes si la version majeure est un zéro. Un numéro de version majeur nul indique que le logiciel est en développement rapide et n’a pas d’API stable. Cela signifie également que chaque augmentation mineure peut avoir des changements de rupture. Un exemple de ceci est React Native qui est actuellement sur la version 0.57.8, cela signifie que la mise à niveau vers la version 57 à partir de 56 peut nécessiter des modifications de code et peut ne pas être compatible avec d’autres dépendances du projet. Les mises à jour de correctifs doivent toujours être considérées comme rétrocompatibles

Pourquoi est-ce important?

Après avoir lu tout cela, vous pensez peut-être: « Je ne prévois pas de publier une bibliothèque ou un package npm. Pourquoi le savoir est-il utile? »Tout d’abord, je vous recommande fortement de publier un package. Vous apprendrez beaucoup en passant par le processus. Deuxièmement, en tant que développeur qui apporte ces bibliothèques et paquets, il est important de les tenir à jour et ce système de gestion des versions aide à prendre des décisions pour mettre à jour vos dépendances non seulement plus faciles à prendre, mais automatisées.

Lorsque vous installez un package à partir de npm, vous remarquerez que votre package.json sera mis à jour et ressemblera éventuellement à ceci:

"dependencies": { "react": "^16.6.3", "react-clean-form": "^2.1.2", "react-dom": "^16.6.3", "styled-components": "^4.1.1"},

Vous remarquerez que devant chacun de leurs numéros de version se trouve un carat. Ce que cela indique à npm (ou yarn) que vous voulez la dernière version qui est toujours rétrocompatible avec le numéro de version. Si vous vouliez vous assurer que vous n’avez que des mises à jour de correctifs et non des mises à jour de versions mineures, vous ajouteriez un tilde au lieu du carat comme ceci: "react": "~16.6.3" et enfin, si vous mettez simplement le numéro de version, vous n’obtiendrez que cette version spécifique. Fondamentalement, vous indiquez à quel niveau de rétrocompatibilité êtes-vous à l’aise avec.

Cette convention permet à votre gestionnaire de paquets de prendre des décisions intelligentes pour vous. Si je devais cloner le projet ci-dessus et exécuter npm install. Je n’obtiendrais pas la version 16.6.3 de react, j’obtiendrais plutôt la version 16.7.0. En effet, 16.7.0 est toujours rétrocompatible avec 16.6.3, mais est plus à jour avec les derniers correctifs et fonctionnalités. Lorsque vous exécutez npm update, il n’installe pas seulement la dernière version rétrocompatible selon vos règles, il modifie également le numéro de version dans votre package.json aussi. Lorsque vous exécutez npm audit-fix, cela indique à npm d’exécuter npm update sur les packages qui ont des problèmes de sécurité connus afin que vous puissiez obtenir les derniers correctifs. Si le correctif est dans une version qui ne correspond pas à vos règles de confort, il vous indiquera que vous devez le réparer manuellement.

Semver est un outil puissant. Avec trois chiffres, les auteurs peuvent communiquer des informations très importantes aux consommateurs de leurs logiciels. Cela nous permet en tant que consommateurs d’automatiser la tâche fastidieuse de maintenir notre logiciel à jour en fonction de notre niveau de confort et de passer plus de temps et les tâches que nous aimons faire: écrire un code incroyable qui résout les problèmes. Pour une explication plus complète de semver, je vous recommande de vérifier semver.org

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.