Pourquoi build.number est-il un "abus" du versioning sémantique?
J'expliquais un système de construction proposé (Gradle/Artifactory/Jenkins/Chef) à l'un de nos architectes seniors, et il m'a fait un commentaire selon lequel je en quelque sorte en désaccord avec, mais je n'ai pas assez d'expérience pour vraiment peser.
Ce projet construit une Java (JAR) en tant qu'artefact à réutiliser par d'autres équipes. Pour le versionnage, j'aimerais utiliser l'approche sémantique de:
<major>.<minor>.<patch>
Où patch indique des corrections de bogues/d'urgence, minor indique des versions rétrocompatibles et major indique des refactorisations massives de l'API et/ou des modifications incompatibles en amont.
En ce qui concerne la livraison, voici ce que je veux: un développeur valide du code; cela déclenche une construction vers un environnement QA/TEST. Certains tests sont exécutés (certains automatisés, certains manuels). Si tous les tests réussissent, une version de production publie le fichier JAR dans notre référentiel interne. À ce stade, le JAR doit être correctement versionné, et ma pensée était d'utiliser le build.number qui est généré automatiquement et fourni par notre outil CI pour servir de numéro de patch.
Ainsi, le versioning serait en fait:
<major>.<minor>.<build.number>
Encore une fois, où build.number est fourni par l'outil CI.
L'architecte a rejeté cette affirmation, affirmant que l'utilisation du numéro de build CI était un "abus" du versioning sémantique.
Ma question est: est-ce exact, et si oui, pourquoi? et si non, pourquoi pas?
Votre numéro de build ne sera pas réinitialisé à 0, lorsque les versions mineures et majeures augmentent, cela viole les sections 7 et 8 des spécifications :
La version mineure Y (x.Y.z | x> 0) DOIT être incrémentée si de nouvelles fonctionnalités rétrocompatibles sont introduites dans l'API publique. Il DOIT être incrémenté si une fonctionnalité 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 (X.y.z | X> 0) DOIT être incrémentée si des modifications incompatibles en amont sont introduites dans l'API publique. Il PEUT inclure des changements mineurs et de niveau de patch. Le correctif et la version mineure DOIVENT être réinitialisés à 0 lorsque la version principale est incrémentée.
Ainsi, les numéros de version (majeur, mineur, correctif) doivent être fournis manuellement, car ils sont utilisés pour informer vos utilisateurs des changements en un seul endroit sans qu'ils aient à consulter votre journal des modifications ou un autre document.
Si vous souhaitez inclure votre numéro de build, vous pouvez les ajouter après un + (section 10):
Les métadonnées de construction PEUVENT être indiquées en ajoutant un signe plus et une série d'identificateurs séparés par des points immédiatement après le correctif ou la version préliminaire. Les identificateurs DOIVENT comprendre uniquement ASCII alphanumériques et tiret [0-9A-Za-z-]. Les identificateurs NE DOIVENT PAS être vides. Les métadonnées de construction DEVRAIENT être ignorées lors de la détermination de la priorité de la version. Ainsi, deux versions qui ne diffèrent que dans les métadonnées de génération, ont la même priorité. Exemples: 1.0.0-alpha + 001, 1.0.0 + 20130313144700, 1.0.0-beta + exp.sha.5114f85.
L'une des raisons est que le correctif peut nécessiter plusieurs versions, donc si vous avez la version 5.7 et que vous souhaitez la corriger en 5.7.1, mais vos 2 premiers correctifs de bogues ne parviennent pas à se construire lorsqu'ils sont soumis au système CI, alors vous serez à 5.7.3 avant de sortir votre premier patch!
La réponse est d'utiliser simplement 4 chiffres (comme les systèmes Microsoft ont tendance à le faire). Le 4ème est un numéro de build et est utilisé "à titre indicatif". Généralement, les gens y mettent le numéro de version du référentiel (s'ils utilisent SVN ou TFS ou similaire), ce qui est vraiment bien car vous pouvez vérifier quel commit exact a été utilisé pour construire les binaires. Si vous n'avez pas une telle chose, alors le numéro de build du CI est une approximation raisonnable (comme vous espérez que votre système CI peut se souvenir des numéros de build et le lier à l'historique du dépôt, mais vous ne dépendez pas du CI système les mémorisant - vous ne pouvez jamais supprimer d'anciennes versions).
Une chose à noter, le schéma Microsoft pour le contrôle de version utilise la 3e position pour les numéros de build. Chrome utilise un seul chiffre. Ubuntu utilise la date. Il n'y a pas de "standard" à utiliser , sauf que tous les nombres doivent être incrémentés.