Bonjour,
aujourd’hui je vous propose un petit tutoriel qui est à mis chemin entre un guide pour les développeurs et une explications sûr comment fonctionnent les versions dans Sponge.
Tout d'abord, et avant de renter réellement dans le sujet, je vous invite à vous renseigner sur Sponge si vous ne savez pas ce que c'est. Pour ce faire, vous pouvez par exemple consulter l’introduction du tutoriel dédié écrit par @robin4002 qui explique très bien ce point.
Ce guide va donc vous permettre d'adopter une nomination des versions propres, standardisé et cohérentes. Comme petite étude de cas, nous allons prendre Sponge mais il faut bien se rendre compte que ce standard est utilisé bien au-delà de Minecraft, dans l'informatique en général. Vous vous en êtes peut-être déjà rendu compte si vous avez développé un projet dans le temps, mais les noms des versions sont un point-clé. Il faut qu'en quelques caractères, il soit facile de savoir où on se situe dans l'avancement chronologique de votre projet.
Si vous avez déjà un peu réfléchi à ce sujet, vous avez surement adopté un standard plutôt classique, qui est X.Y. C'est-à-dire que votre première version commence à 0.1 ou 1.0 et vous incrémentez X à chaque mise à jour que vous jugez majeure et Y sinon. Il est donc envisageable d'avoir une version 1.5, mais aussi 2.3 ou 1.48 par exemple. Ce système fonctionne bien mais est un peu artisanal, notamment dû au fait que "grosse mise à jour" est subjective. Si vous travaillez tout seul sur votre projet (où qu'un responsable est là pour trancher), ça fonctionne plutôt bien ; mais, si vous êtes une plus grande équipe ou que vous souhaitez qu'un inconnu puisse facilement se retrouver dans votre nomination des versions, c'est moins adapté.
C'est pour ça qu'existe SemVer, ou Semantic Versioning. La philosophie de SemVer est simple, une version X.Y.Z avec des règles précises d'incrémentation de X, Y et Z. Ces X, Y et Z sont aussi appelés MAJOR pour X, MINOR pour Y et PATCH pour Z (vous allez rapidement comprendre pourquoi).
Pour être certains que ce soit bien clair pour tous, exemple rapide. Considérons la version 4.2.18 dans la norme SemVer. X ou le Major vaut 4 (c'est-à-dire que c'est la quatrième mise à jour majeure) ; Y ou le Minor correspond à 2 (c'est-à-dire que c'est la deuxième mise à jour mineur depuis la version 4) et Z ou le Patch correspond à 18 (c'est-à-dire que c'est la dix-huitième correction de la version 4.2).
Je vous disais plus haut que les règles d'incrémentation de X, Y et Z sont précises, et les voici donc :
Maintenant que ces règles sont établies, plusieurs exemples pratiques avec Sponge :
Si vous souhaitez en savoir plus sur la gestion des versions Sponge, je vous invite à lire la documentation (disponible en français !). Elle est en réalité un peu plus riche que ce que je vous présente ici.
SemVer propose encore deux choses dont j'aimerais rapidement vous parler sans trop rentrer dans les détails.
Tout d'abord, vous pouvez ajouter des précisions sur vos versions. Par exemple, si vous publiez une pre-release ou une release candidate vous pouvez ajouter respectivement -prerelease ou -candidate après le nom de votre version. Ce qui donne par exemple, 4.2.6-prerelease ou encore 1.7.0-candidate. Par exemple, Sponge utilise -snapshot pour indiquer qu'il s'agit de la prochaine version en développement de l'API.
Le deuxième point dont j'aimerais vous parler pour conclure sont les intervalles et symboles logiques dans SemVer. Vous les avez peut-être rencontré sans le savoir, notamment dans les frameworks web, c'est les versions dénotées par ~1.2 ou ^1.2 par exemple. Il existe quelques symboles spéciaux comme ~ qui signifie "assez proche de", ^ qui signifie compatibles avec ou * et x qui signifient toutes les versions (la dernière possible en l’occurrence). C'est pour ça qu'une notation ~1.2 dans les frameworks web qui implémentent SemVer vous prendre la version 1.2 maximum qui existe, c'est-à-dire celle avec le niveau de Patch le plus important.
Il faut savoir que SemVer est encore un peu plus complet que ce que j'ai abordé ici mais je pense avoir déjà bien fait le tour sans rentrer dans des détails trop techniques. Pour en apprendre encore plus, je ne peux que vous conseiller ce site qui vous sera très utile si vous souhaitez utiliser SemVer.
Si vous avez des questions sur les versions sémantiques, n’hésitez pas ! Dans tous les cas, j'espère que ce guide vous aura été utile !
aujourd’hui je vous propose un petit tutoriel qui est à mis chemin entre un guide pour les développeurs et une explications sûr comment fonctionnent les versions dans Sponge.
Tout d'abord, et avant de renter réellement dans le sujet, je vous invite à vous renseigner sur Sponge si vous ne savez pas ce que c'est. Pour ce faire, vous pouvez par exemple consulter l’introduction du tutoriel dédié écrit par @robin4002 qui explique très bien ce point.
Ce guide va donc vous permettre d'adopter une nomination des versions propres, standardisé et cohérentes. Comme petite étude de cas, nous allons prendre Sponge mais il faut bien se rendre compte que ce standard est utilisé bien au-delà de Minecraft, dans l'informatique en général. Vous vous en êtes peut-être déjà rendu compte si vous avez développé un projet dans le temps, mais les noms des versions sont un point-clé. Il faut qu'en quelques caractères, il soit facile de savoir où on se situe dans l'avancement chronologique de votre projet.
Si vous avez déjà un peu réfléchi à ce sujet, vous avez surement adopté un standard plutôt classique, qui est X.Y. C'est-à-dire que votre première version commence à 0.1 ou 1.0 et vous incrémentez X à chaque mise à jour que vous jugez majeure et Y sinon. Il est donc envisageable d'avoir une version 1.5, mais aussi 2.3 ou 1.48 par exemple. Ce système fonctionne bien mais est un peu artisanal, notamment dû au fait que "grosse mise à jour" est subjective. Si vous travaillez tout seul sur votre projet (où qu'un responsable est là pour trancher), ça fonctionne plutôt bien ; mais, si vous êtes une plus grande équipe ou que vous souhaitez qu'un inconnu puisse facilement se retrouver dans votre nomination des versions, c'est moins adapté.
C'est pour ça qu'existe SemVer, ou Semantic Versioning. La philosophie de SemVer est simple, une version X.Y.Z avec des règles précises d'incrémentation de X, Y et Z. Ces X, Y et Z sont aussi appelés MAJOR pour X, MINOR pour Y et PATCH pour Z (vous allez rapidement comprendre pourquoi).
Pour être certains que ce soit bien clair pour tous, exemple rapide. Considérons la version 4.2.18 dans la norme SemVer. X ou le Major vaut 4 (c'est-à-dire que c'est la quatrième mise à jour majeure) ; Y ou le Minor correspond à 2 (c'est-à-dire que c'est la deuxième mise à jour mineur depuis la version 4) et Z ou le Patch correspond à 18 (c'est-à-dire que c'est la dix-huitième correction de la version 4.2).
Je vous disais plus haut que les règles d'incrémentation de X, Y et Z sont précises, et les voici donc :
- on ajoute 1 à X (Major) lorsque la version contient des changements d'API incompatible avec la version précédente. En des termes plus simples, lorsque certaines parties de l'API vont casser pour les développeurs.
- on ajoute 1 à Y (Minor) lorsque les fonctionnalités sont ajoutées mais sans casser l'API (backwards-compatible / rétro-compatibilité). Il doit être possible de faire tourner un code écrit avec une version de l'API antérieur à la nouvelle version sans que rien ne casse (des avertissements peuvent apparaitre par contre, comme des fonctions qui sont maintenant découragées et qui casseront à la prochaine Major).
- on ajoute 1 à Z (Patch) dans le cas de correctement de bugs, toujours avec une rétro-compatibilité.
Maintenant que ces règles sont établies, plusieurs exemples pratiques avec Sponge :
- imaginons que mon serveur Sponge est en 7.0.3 et que j'ai un plugin qui a été écrit pour Sponge 6.9.x (x dénotant une inconnue qui n'a pas d'importance). Il ne m'est pas possible d'affirmer que je pourrais faire tourner ce plugin dans 100% des cas sur mon serveur. En effet, la Major est différente, il est donc possible et même, probable, que certaines fonctions qu'utilise mon plugin n'existent plus dans Sponge !
- autre exemple, j'ai un plugin développé pour Sponge 6.4.x et mon serveur est en 6.5.1. Il m'est possible de faire fonctionner ce plugin car les Minor sont rétro-compatibles. Je pourrais cependant obtenir des avertissements à l'utilisation.
- dernier exemple, j'ai un serveur en Sponge 6.1.3 et un plugin développé pour 6.2. Je ne suis pas garanti que ce plugin fonctionne, car il manque peut-être des fonctions dans ma version actuelle.
Si vous souhaitez en savoir plus sur la gestion des versions Sponge, je vous invite à lire la documentation (disponible en français !). Elle est en réalité un peu plus riche que ce que je vous présente ici.
SemVer propose encore deux choses dont j'aimerais rapidement vous parler sans trop rentrer dans les détails.
Tout d'abord, vous pouvez ajouter des précisions sur vos versions. Par exemple, si vous publiez une pre-release ou une release candidate vous pouvez ajouter respectivement -prerelease ou -candidate après le nom de votre version. Ce qui donne par exemple, 4.2.6-prerelease ou encore 1.7.0-candidate. Par exemple, Sponge utilise -snapshot pour indiquer qu'il s'agit de la prochaine version en développement de l'API.
Le deuxième point dont j'aimerais vous parler pour conclure sont les intervalles et symboles logiques dans SemVer. Vous les avez peut-être rencontré sans le savoir, notamment dans les frameworks web, c'est les versions dénotées par ~1.2 ou ^1.2 par exemple. Il existe quelques symboles spéciaux comme ~ qui signifie "assez proche de", ^ qui signifie compatibles avec ou * et x qui signifient toutes les versions (la dernière possible en l’occurrence). C'est pour ça qu'une notation ~1.2 dans les frameworks web qui implémentent SemVer vous prendre la version 1.2 maximum qui existe, c'est-à-dire celle avec le niveau de Patch le plus important.
Il faut savoir que SemVer est encore un peu plus complet que ce que j'ai abordé ici mais je pense avoir déjà bien fait le tour sans rentrer dans des détails trop techniques. Pour en apprendre encore plus, je ne peux que vous conseiller ce site qui vous sera très utile si vous souhaitez utiliser SemVer.
Si vous avez des questions sur les versions sémantiques, n’hésitez pas ! Dans tous les cas, j'espère que ce guide vous aura été utile !
![[coco24200]](/forum/data/avatars/s/38/38530.jpg?1338224835){kind=avatar}
