Discussion :

[bassemeco]

Bonjour messieurs je voudrais savoir quel strategie de versionnement avez vous quand vous faites des releases?
Comment procedez vous?

J'éspère que j'ai été clair

bassem

[romaintaz]

De notre côté, nous travaillons comme ça (c'est discutable, mais c'est un choix) :

L'équipe de dév est actuellement en train de travailler sur la release 1.0-RCX-SNAPSHOT, X étant un nombre entier, bien sûr.
Quand on déploie en environnement de DEV, on ne change rien.
Si c'est une release en HOMOLOGATION (testable par les MOA quoi), on release la version 1.0-RCX. Il y a un léger code freeze niveau développeurs. Puis, on passe à la version 1.0-RCX+1-SNAPSHOT.
Et ainsi de suite...
On va bientôt passer en prod', donc le 1.0-xxx va évoluer pour passer sur des 1.1-xxx...

Est-ce assez clair ?

Comme je l'ai dit, ça reste une façon de faire.

Sinon, tu peux jeter un oeil sur le plugin release, qui se charge entre autre de re-versionner les pom.xml lors de releases...

[bassemeco]

Je n'ai pas vraiment saisi.
Nous on est encore a la 0.9 et justement on me demande de proposer une strategie de versionnement.

Pourrai tu polus developper stp romain tu m'aiderai.
J'ai compris les grandes traces.

[romaintaz]

Nous les développeurs, nous faisons évoluer l'application en permanence. C'est pour ça que nous utilisons des versions xxx-SNAPSHOT...

Le principe pour nous est le suivant :

On travaille en 1.0-RC6-SNAPSHOT, par exemple.
On déploie en DEV à un moment donné, on reste en 1.0-RC6-SNAPSHOT.
On continue, puis à un moment, on décide de déployer en HOMOLOGATION.
On fait un code freeze (personne ne commite quoi).
Le release manager fait passer l'appli en 1.0-RC6, taggue le tout, compile et déploie l'application. La version déployée en HOMOL est donc la 1.0-RC6.
Il passe alors les versions des pom.xml en 1.0-RC7-SNAPSHOT, commite, et supprime le code freeze.
Les développeurs se mettent à jour, et on code tous sur la 1.0-RC7-SNAPSHOT du coup.
Puis on recommence le cycle, et ainsi de suite.

C'est plus clair ?

Maintenant, nous on abuse un peu du "RC" (Release Candidate), puisque dès le début, on a commencé à coder en 1.0-RC1-SNAPSHOT alors que c'était pas du tout une RC. Aujourd'hui, on est en 1.0-RC18-SNAPSHOT
Tu peux donc proposer au lieu de 1.0-RCX-SNAPSHOT une version 0.X-SNAPSHOT. Le principe important est la façon de gérer le xxx-SNAPSHOT, de savoir quand l'enlever, etc.

[romaintaz]

Une chose que je n'ai pas abordé : les branches.

Généralement, une fois qu'on passe en 1.0, donc en prod, on travaille sur 2 branches, la branche étant créée le jour où on passe en 1.0 :
Une branche pour les bug fixes de la 1.0 (pour les versions 1.0.x donc) et une autre pour la prochaine grosse version de l'appli (1.1 ou 2.0 par ex.)

[bassemeco]

merci romain c'est parfait.

ps:ca m'aiderai de connaitre la strategie de versionnment des autres.
Merci a vous
bassem

[bassemeco]

Bonjour messieurs,
J'aimerai bien avoir d'autres strategie de developpemement,la manière dont vous procedez.
Vous ne faites quand même pas tous comme romaintaz.

N'y a t-il pas de page web qui serait susceptible d'en parler par hasard?

Bassem