Pourquoi build.number est-il un «abus» du versioning sémantique?

35

J'expliquais un système de construction proposé (Gradle / Artifactory / Jenkins / Chef) à l' un de nos architectes supérieurs, et il a fait un commentaire à moi que je sorte de désaccord avec, mais je suis pas assez expérimenté pour vraiment pesée sur.

Ce projet crée une bibliothèque Java (JAR) en tant qu'artefact pouvant être réutilisé par d'autres équipes. Pour la gestion des versions, j'aimerais utiliser l'approche sémantique de:

<major>.<minor>.<patch>

Où patchindique un correctif de bogue / urgence, minorindique les versions à compatibilité ascendante, et majorindique soit des refactorisations massives de l'API et / ou des modifications incompatibles avec les versions antérieures.

En ce qui concerne la livraison, voici ce que je veux: un développeur commet du code; cela déclenche une construction dans un environnement QA / TEST. Certains tests sont exécutés (certains automatisés, certains manuels). Si tous les tests réussissent, une génération de production publie le fichier JAR dans notre référentiel interne. À ce stade, le fichier JAR doit être mis à jour correctement, et je pensais utiliser le build.numberfichier généré automatiquement et fourni par notre outil de CI pour agir en tant que numéro de correctif.

Ainsi, le versioning serait en réalité:

<major>.<minor>.<build.number>

Là encore, où build.numberest fourni par l'outil de CI.

L'architecte a rejeté cet argument, affirmant que l'utilisation du numéro de build de CI constituait un "abus" du versioning sémantique.

Ma question est la suivante: est-ce correct et si oui, pourquoi? et si non, pourquoi pas?

continuous-integration versioning builds continuous-delivery semantic-versioning herpylderp
la source

Réponses:

45

Votre numéro de build ne sera pas réinitialisé à 0, lorsque les versions mineures et majeures augmenteront, cela violera les sections 7 et 8 des spécifications :

La version mineure Y (xYz | x> 0) DOIT être incrémentée si une nouvelle fonctionnalité rétrocompatible est introduite dans l'API publique. Il DOIT être incrémenté si une fonctionnalité de l'API publique est marquée comme obsolète. Il PEUT être incrémenté si de nouvelles fonctionnalités ou améliorations substantielles sont introduites dans le code privé. Il PEUT inclure des changements de niveau de patch. La version du correctif DOIT être réinitialisée à 0 lorsque la version mineure est incrémentée.

La version majeure X (Xyz | X> 0) DOIT être incrémentée si des modifications incompatibles avec les versions antérieures sont introduites dans l'API publique. Il PEUT inclure des modifications mineures et de niveau de correctif. Le correctif et la version mineure DOIVENT être réinitialisés à 0 lorsque la version majeure est incrémentée.

Ainsi, les numéros de version (majeur, mineur, correctif) doivent être fournis manuellement, car ils servent à informer vos utilisateurs des modifications apportées à un endroit donné sans qu'ils aient à consulter votre journal des modifications ou tout autre document.

Si vous souhaitez inclure votre numéro de build, vous pouvez les ajouter après un +(section 10):

Construire des métadonnées PEUT être noté en ajoutant un signe plus et une série d’identifiants séparés par des points immédiatement après le correctif ou la version préliminaire. Les identifiants DOIVENT comprendre uniquement des caractères alphanumériques ASCII et un trait d'union [0-9A-Za-z-]. Les identifiants NE DOIVENT PAS être vides. Les métadonnées de construction DEVRAIENT être ignorées lors de la détermination de la priorité des versions. Ainsi, deux versions ne différant que par les métadonnées de construction ont la même priorité. Exemples: 1.0.0-alpha + 001, 1.0.0 + 20130313144700, 1.0.0-beta + exp.sha.5114f85.

Résidu
la source
Suivi rapide @Residuum (et BTW +1 pour la réponse): les numéros de version doivent-ils toujours être dérivés manuellement? Si non, quels outils pourraient être utilisés à la place du numéro de CI / build?
herpylderp
1
@herpylderp pas du tout, la «spécification» de Tom Preston-Werner n’est que son opinion, de nombreuses autres sociétés ont des normes différentes (généralement très similaires les unes aux autres). Dans la plupart des cas, un numéro généré automatiquement fait partie de la version. Utiliser le numéro de build de CI est une chose sensée à faire.
gbjbaanb
Vous pouvez toujours utiliser l'outil de CI si cet outil vous permet de calculer des nombres sur des nombres. Quelle que soit la version que vous publiez en tant que mise à niveau de version majeure ou mineure, insérez ce numéro de version dans une expression de la chaîne de version qui soustrait du numéro de version actuel du CI. Voilà, vous venez de réinitialiser votre numéro de build à zéro pour la nouvelle version, sans réinitialiser réellement votre numéro de build.
KeithS
2
Quant à moi, je viens d'utiliser [majeur]. [Mineur]. [Révision]. [SVN-Version] pour les DLL et [majeur]. [Mineur]. [SVN-Version] pour les installateurs. Le numéro de build du CI est destiné à un usage interne uniquement, afin d'indiquer où une génération ayant échoué pourrait avoir été réexécutée avec exactement la même base de code après une modification de l'environnement du CI (installation d'un certificat de clé, ajout de bibliothèques communes au GAC, etc.).
KeithS
1
@ gbjbaanb et al .: Dans chaque discussion sur le "versioning sémantique" à laquelle je faisais partie, la définition de semver.org était le sujet. Recherchez sur le Web "versioning sémantique", et au moins la première page présente des arguments pour / contre la définition de semver.org . Vous êtes libre d'utiliser vos propres schémas de version, mais ne l'appelez pas versioning sémantique, car ce terme est clairement défini.
Residuum
2

Une des raisons est que le correctif peut nécessiter plusieurs versions. Par conséquent, si vous avez la version 5.7 et que vous souhaitez la corriger vers la version 5.7.1, mais que vos deux premiers correctifs de bogues ne parviennent pas à se créer lorsqu'ils sont soumis au système CI, à 5.7.3 avant de publier votre premier patch!

La solution consiste simplement à utiliser 4 chiffres (comme le sont généralement les systèmes Microsoft). Le 4ème est un numéro de build et est utilisé "pour information seulement". Généralement, les gens y mettent le numéro de version du référentiel (s’ils utilisent SVN, TFS ou un logiciel similaire), ce qui est très pratique, car vous pouvez vérifier le commit exact utilisé pour construire les fichiers binaires. Si vous ne possédez pas une telle chose, alors le nombre de build de CI est une approximation raisonnable (car vous espérez que votre système de CI peut mémoriser les numéros de build et le lier à l'historique des pensions, mais vous ne comptez pas sur le CI. système en les mémorisant - vous ne pouvez jamais supprimer les anciennes versions).

Une chose à noter, le schéma Microsoft pour la gestion des versions utilise la 3ème position pour les numéros de build. Chrome utilise un seul numéro. Ubuntu utilise la date. Il n'y a pas de "standard" à utiliser , sauf que tous les nombres doivent être incrémentés.

gbjbaanb
la source
5
Bien qu'il n'y ait pas de norme universellement utilisée ou appliquée, la question semble concerner spécifiquement le versioning sémantique qui a une spécification.
Doval
Même si cela est cassé sur le terrain, par exemple, le versioning NuGet de Microsoft utilise semver, de manière cassée (en utilisant le style de pré-édition pour les numéros de build), et Ruby utilise major.minor.teeny.patch . Quoi qu’il en soit, comme le numéro de build peut faire partie du semver, l’architecte parlait à tosh (bien qu’il soit vrai, il devrait être + build, pas en 3ème position).
gbjbaanb
2
La spécification SemVer 2.0 date de 2013 et la spécification 1.0, celle de 2012 pour autant que je sache. Il est probable que NuGet et Ruby ont fait leur propre chose avant que la spécification ne soit apparue. Ce n'est pas comme si la spécification SemVer était nouvelle; il ne fait que formaliser ce que les gens ont déjà fait afin que nous puissions finalement tous nous mettre d’accord sur une façon de le faire au lieu d’une douzaine de variantes.
Doval
"vous avez la version 5.7 et vous voulez le corriger à la version 5.7.1, mais vos 2 premières corrections de bogues ne parviennent pas à se créer lorsqu'elles sont soumises au système CI, vous arriverez à la version 5.7.3 avant la publication de votre premier correctif ! " ok, mais alors quoi? Je ne me souviens de rien dans les mots qui disent que les chiffres ne doivent pas être ignorés.
Andy