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ù patch
indique un correctif de bogue / urgence, minor
indique les versions à compatibilité ascendante, et major
indique 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.number
fichier 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.number
est 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?