Bon, je suis en plein débat avec @Philou et @CCous pour savoir si oui ou non il faut commiter les changements de version de la balise <version> de nos pom.xml.

En quoi y a-t-il débat ?

C'est assez simple, je suis partisane du fait qu'il soit nécessaire de commiter le numéro de version des pom.xml et de tagger le commit qui contient cet incrément. Je ne crois pas qu'il faille le faire pour tout, mais la chose est indispensable a minima pour les libs.

Mon argument est que Maven doit être indépendant du gestionnaire de version qui dans l'histoire a changé de nombreuses fois. Pour info, j'ai eu la "chance" de coder sur un projet qui est passé dans cet ordre de Synergy à SVN puis à Git en moins de deux ans ! #TropBien

Bref, le script pour la conf de build sont des sources et il est normal de les tagger avec le code d'autant qu'il s'agit du comportement de base de l'outil.

L'argument que m'oppose @Philou (en dehors du el famoso c'est le progrès faut faire avec son temps), c'est qu'une release consomme énormément de temps de build au niveau des serveurs d'intégration continue, d'autant plus qu'une release exécutée avec le maven-release-plugin impose de rebuilder deux fois la même chose.

Et mon problème c'est que je suis à la fois d'accord avec @Philou mais je suis aussi d'accord avec moi-même ! #SaletéDeSchizophrénie

Donc j'ai décidé de creuser la question afin d'avoir le meilleur des deux mondes qui consisterait :

• À préserver un numéro de version unique, commun à tous les outils et parfaitement tenu à jour.
• À ne pas augmenter inutilement la charge des serveurs d'intégration continue qui sont souvent à la limite de la rupture. (Pour info, les jobs de build de @Philou durent plus de 6h... Juste un job oui... Donc l'argument du "faut pas rebuilder" est indiscutable)

Solutions possibles

La solution de @Philou et @CCous consiste à ne plus toucher aux versions des POM, mais qu'au moment de la publication dans Nexus ou Artifactory, le haché du commit soit récupéré ainsi que la date du jour et le nom de la branche pour construire un numéro de version unique à base d'une grosse concaténation afin d'estampiller ce dernier dans le répo d’artefacts.

J'oppose à cette bidouille une toute autre bidouille : lors de la release on incrémente le numéro de version mais on ne rebuild pas le code, à ce moment on se contente de récupérer le jar du commit précédent pour le republier sous un nouveau nom. De cette façon le numéro de version de Maven est bien incrémenté et les temps de build du CI restent courts y compris pendant la release (j'en ai déjà parlé avec @Kysofer et il va peut-être nous pondre un plugin Maven).

NDR : soyons clairs, tout cela relève de la grande bidouille mais quand il faut y aller il faut y aller.

En quoi consiste le lien ?

Simplement pour notifier tout le monde que nous ne sommes pas les seuls faisant face à cette problématique et que depuis Maven 3.5.0 trois properties ont été ajoutées afin de faciliter le travail :

• ${revision}
• ${sha1}
• ${changelist}

Ce qui va nous intéresser c'est la property ${revision}, en effet un POM et son enfant ressembleront à ceci mais en contrepartie il faut alimenter le numéro de version dans la ligne de commande en écrivant :

mvn -Drevision=1.0.0-SNAPSHOT clean install

De cette façon, un pom.xml ayant le bon numéro de version sera bien généré par Maven, en parallèle le numéro de version ne requiert plus une procédure de commit redondante qui rallongerait les temps de build, le numéro de version peut devenir dynamique et injectable via le C ; et puisque l'on s'inscrit dans ce que propose Maven alors si un développeur voit ${revision}, il saura que le numéro de version est dorénavant injecté au build et donc qu'on ne tord plus le coup à l'outil pour produire des révisions fictives dans un référentiel de binaires au détriment de la cohérence.

Je dirais que la contrepartie c'est de systématiquement publier le jar des sources avec le jar exécutable afin de préserver la corrélation entre version des sources et version du pom.

Je conclurais en affirmant que les problématiques de build sont pénibles et s'apparentent à de la botanique ! (c) @Chlouchloutte

Très très bonne idée pour des rollback facile !

Des règles de bon sens pour la gestion multi-branche sur des équipes en "mode projet" et codant sur les mêmes répos (tout en releasant à des instants différents).

Le même article mais en plus joli : http://www.infoq.com/articles/agile-version-control