Discussion :

[boutss]

Bonjour,

Je viens à la collecte d'information.
Ma question globale, comment fonctionne les releases candidates ?

Mon contexte :
J'ai un projet A qui pointe vers l'archi B de version 1.0 et un développeur sur chacun d'eux.

Si le dev A à besoin d'une nouvelle fonctionnalité de l'archi, il faut proposer une archi RC-1.1 que le dev A puisse implémenter pour le tester et commiter ses modifications dans le gestionnaire de configuration sans que l'usine logicielle ou les autres développeurs n'en soient perturbés (erreur de compilation).

- Quelle est la manipulation à faire pour effectuer une RC plutôt qu'une release et inversement ?

Point à respecter :
- Il faudrait que l'intégration technique ne puisse pas assembler lorsque les dépendances pointent vers une RC

En gros, je souhaite implémenter la procédure de release candidate pour régler des problèmes de non régression et accélérer les tests et des implémentations des nouvelles fonctionnalités issues des composants externes.

Si je ne suis pas très clair ne pas hésiter à me le dire.

Merci à vous.

Vincent

[boutss]

En gros c'est votre retour d'expérience sur le sujet qui m'intéresse.
Pour info j'ai lu le livre Apache Maven que j'ai sous le coude si vous voulez m'en faire référence.

Merci encore.

[tchize_]

C'est pas un RC qu'il vous faut c'est des snapshots.

En gros, B dans son processus de travail va tous les jours générer des snapshots (normalement), avec idéalement un serveur d'intégration continue qui build en continu le repository de code où se trouvent les snapshots.


Ensuite, A qui a besoin de tester l'intégration avec une future release de B, au lieu de pointer vers B en version 1.0 pointera par exemple vers B en version 1.1-SNAPSHOT


Le snapshot en maven on ceci de particulier que
maven ira tous les jours chercher la dernière version
si il y a des dépendance vers des snapshot, la commande mvn release refusera de fonctionner.


Ensuite quand B et A son d'accord, B fait une vrai release de la 1.1 que A utilisera alors. Et si elle marche pas pour une raison de dernière minute (qui normalement aurait du déjà être visible avec les snapshots), B entamera le cycle des 1.2 snapshot et on repart pour un tour de stabilisation

Maintenant si t'as vraiment besoin de faire des releases candidates séparées des snapshot, il y a aussi la possibilité de faire

mvn Release: 1.0
1.1-SNAPSHOT
1.1-SNAPSHOT
1.1-SNAPSHOT
1.1-SNAPSHOT
1.1-RC1-SNAPSHOT
mvn release: 1.1-RC1
1.1-RC2-SNAPSHOT
1.1-RC2-SNAPSHOT
mvn release: 1.1-RC2
1.1-RC3-SNAPSHOT
1.1-RC3-SNAPSHOT
1.1-RC3-SNAPSHOT
1.1-RC3-SNAPSHOT
mvn release: 1.1-RC3
mvn release: 1.1
1.2-SNAPSHOT

Et toutes es variantes que vous pouvez imaginer

[boutss]

Merci de la réponse.
Alors effectivement il y a bien une Intégration continue qui constitue les SNAPSHOT chaque soir et nous, lorsque l'on souhaite tester une évolutions on pointe sur cette SNAPSHOT via un profil.
Le seul problème dans ce cas de figure, c'est que l'on ne peut pas commiter nos modifications car les autres eux pointent vers une version releasé, normal.

L'avantage que je voyais entre la SNAPSHOT et la RC, c'est que je pouvais modifier la version de la dépendance dans le pom pour le répercuter à tout le monde (équipe + IC) car c'est en soi une vrai version et non évolutive comme une SNAPSHOT.

[tchize_]

c'est une très mauvaise idée de mettre la snapshot "juste chez vous", vous risquez simplement de commiter du code qui ne marchera pas avec la version "non snapshot" qu'utilisent les autres devs du projet. Si vous avez besoin d'une snapshot, vous l'utilisez directement dans le pom et vous commitez le pom. Lors de la release future, c'est à ce moment là qu'on retirera la snapshot du pom.

A noter que pour la "stabilité" vous pouvez aussi viser un snashot particulière en donnant le numéro de version complet du genre 1.1-SNAPSHOT-20110809124523.1245432

[boutss]

Oui effectivement.

Lors de la release future, c'est à ce moment là qu'on retirera la snapshot du pom

ça serait fait manuellement ou automatiquement ?

Merci.