Numéros de Version

Votre plugin a besoin d’un numéro de version unique afin de permettre aux humains de savoir quelle version d’un plugin suit une autre. Il y a plein de schémas de versions que vous pouvez utiliser pour votre propre plugin. Dans la partie suivante, nous allons expliquer quelques concepts avec leurs avantages et inconvénients.

Sponge recommande d’utiliser un identificateur de version qui consiste de deux ou trois parties numériques séparées par un ., et une étiquette additionnelle ajoutée avec un tiret -, comme 3.1 ou 1.0.3-API7 similairement à SemVer. Commencez par 1.x si votre plugin est prêt. Commencez par 0.x si votre plugin n’est pas encore prêt ou est instable.

Note

Pendant que Sponge recommande d’utiliser le schéma ci-dessus, les auteurs de plugins sont libres de choisir celui qu’ils souhaitent. Gardez à l’esprit que les utilisateurs doivent gérer une multitude de schémas, donc restez simple.

SemVer

SemVer est un schéma de versions sémantique fréquemment utilisé. Il consiste de trois blocs numériques qui sont séparés par un point et des étiquettes additionnelles qui sont ajoutés à l’aide de tirets. Les trois blocs numériques font les parties de version MAJEURE, MINEURE et PATCH.

  • Un changement dans la version MAJEURE indique que vous avez fait des changements dans l’API incompatibles. Réécrire une grande partie de votre plugin ou l’entièreté du plugin compterait également comme des changements incompatibles.

  • Un changement dans la version MINEURE indique qu’une fonctionnalité a été ajoutée sans casser la rétrocompatibilité.

  • Un changement dans la version PATCH indique que des bugs ont été corrigés.

Les étiquettes peuvent être utilisées pour marquer des builds comme pre-releases ou contenir des métadonnées de build comme la version de Minecraft supportée. Si vous augmentez une partie de la version, alors vous allez redéfinir les parties suivantes à 0. En utilisant cette stratégie vous pouvez trouver la dernière version en comparant les blocs de versions avec les autres; cependant, ce schéma ne contient pas d’information sur l’ordre de release pour les versions qui ont deux blocs qui diffèrent. Exemple : La version 1.0.9 serait release après 1.0.8, mais la version 1.1.0 pourrait être release, avant, après ou même en même temps que les autres.

Note

La SpongeAPI utilise ce schéma de versions.

Exemples

  • 0.1.0

  • 1.0.0

  • 1.1.0-SNAPSHOT

  • 3.12.21-API7

Avantages

  • Facile à lire et à comprendre

Inconvénients

  • Principalement orienté pour les API donc les termes ne s’appliquent pas vraiment si vous ne fournissez pas d’API dans votre plugin.

Horodatage

Il s’agit d’un schém de versions moins couramment utilisés, mais également très simple, comme il ne contient pas d’information additionnelle dans les numéros de version. Ça n’a pas d’importance de quel séparateur vous utilisez (si il y en a un) ou quelles parties de la date et du temps vous incluez. Cependant, nous recommandons de mettre les parties de la date et du temps dans l’ordre décroissant de durée comme YYYY-MM-DD. Si vous triez vos fichiers par ordre alphabétique, assurez-vous que l’ordre serait le même que l’ordre des versions. Il est également possible d’ajouter un qualificatif de build ou un numéro de build.

Exemples

  • 18.01.31

  • v2018-05-29.1

  • 2018.01.13-SNAPHOT

Avantages

  • Facile à lire et à comprendre

Inconvénients

  • Ne contient pas d’informations sur la compatibilité.

Autres

Vous pouvez en savoir plus sur le Software versioning et les schémas de versions en ligne.