Par contre, en regardant de plus près, j'ai remarqué que vous aviez
récupérés sur votre dépôt SVN seulement la dernière version du SVN de
Sourceforge. Serait-il possible que vous récupéreriez les commits
précédents ?
Nous avons déjà effectué quelques commits sur le projet après la
migration de svn. Tenez-vous particulièrement aux 14 commits effectués
sur sourceforge ? (Sachant que le svn sourceforge reste disponible)
Autre détail, les nouveaux tickets d'évolution sont renseignés pour la
v1. Serait-il possible de garder les mêmes numéros de versions ? C'est à
dire de laisser les anciens tickets sur la v1 (version actuelle), et que
les évolutions soient dispatchées entre la v1.1 (actuelle prestation) et
la v1.2 (future prestation avec fonctionnalités non retenues).
Concernant les versions, je me pose plusieurs questions. Le trunk était
en version 1.0 (il devrait être en version snapshot), et aucun tag n'est
présent sur le svn.
Nous proposons de faire une release (et donc un tag) 1.0 qui fixe
cantharella dans sa version actuelle. Nous passons ensuite le trunk en
version 1.1-SNAPSHOT et nous effectuons la prestation sur cette version.
A la fin de la prestation, nous faisons une release 1.1, le trunk passe
alors en version 1.2-SNAPSHOT (et nous avons un tag 1.1).
Les tickets de la version actuelle qui sont clos restent sur la version
1.0. Les tickets non clos passent sur la version 1.2, les tickets de la
prestation que nous réalisons passent sur la version 1.1. Si des tickets
sont corrigés, nous les passeront sur la version 1.1.
A la fin de la prestation, resteront sur la version 1.2 (développements
à effectuer), les tickets de bugs non résolus.
Je ne sais pas si je suis clair dans mes explications. Dans le cas
contraire, je vous propose d'en reparler lors de notre visio de la
semaine prochaine.
Vos explications sont très claires. Ok pour suivre cette démarche,
elle se base en plus sur des bonnes pratiques de versioning.