Bonjour à tous,

Quelqu'un aurait-il des liens vers des articles sur la conduite de projet concernant les versions.

A titre d'exemple, je viens de développer une application qui doit absolument sortir, mais pour laquelle il reste quelques manques de fonctionnalités et potentiellement quelques bugs.

Je pense à quelque chose comme :

Version 1 (actuelle) :
-> Stable

Puis, si je dois corriger des bugs, je modifierai la version 1 en incrémentant le chiffre de version mineure (juste deux chiffres ça ira) : 1.1, 1.2, etc

Puis, pour implémenter les fonctionnalités manquantes, je pense créer une version 2 :

Version 2 (qui est une sorte de copie de la version 1 à une date donnée) :
-> Devlopment

Puis, la version 2 passera en beta puis en stable, et ce indépendamment des modifications de la version 1 qui restera toujours en 1.

Mais, déjà, je ne suis pas sûr que ce soit la bonne technique, et de plus, comment implémenter ça avec un système de versions.

La difficulté est d'autant plus grande que chaque version est déclinée en plusieurs logiciels indépendants pour le client final : le logiciel avec un nom A pour le logiciel 1, B pour le logiciel B, etc, associé à une base de donnée propre à chaque version. La base de données elle-même peut recevoir des corrections de bugs et de modifications majeures ; mais le code source du logiciel en lui-même doit être le même quelque soit le logiciel final, pour une version donnée (seul un fichier de config qui indique le nom du logiciel et un certificat AIR change).

Voilà ma problématique

Cordialement,

et bien je vois pas ou est le problème, si tu utilises SVN par exemple tu peux tout à fait gérer des applications distinctes, et faire une release 1.0 basée sur une version du trunk qui contient des fichiers dont le nombre de modifications est différent. Et ainsi de suite pour une 2.0, le fait de faire une copie du trunk vers la 1.0 (une release dans le jargon) ne signifie pas que la 1.0 est finie, il te suffit de continuer à bosser sur le trunk et de faire des copies à chaque fois que le trunk est dans un état satisfaisant. En revanche une fois releasé on ne devrait plus rien modifier si il y a un bug majeur il faut juste faire une nouvelle release.

Salut,

Pour les numeros de version, tu peux jeter un oeil ici: http://fr.wikipedia.org/wiki/Version_d%27un_logiciel

Pour l'organisation de ton depot de code (SCM: source code management), tu peux opter pour deux solutions avec SVN:
1- tu crees un depot, que tu separes en X "sous dossiers" (un par logiciel, l'equivalent des modules avec CVS) contenant chacun leur repertoire trunk, tags, branches
2- tu crees X depots (un par logiciel) contenant chacun leur repertoire trunk, tags, branches

Avantage de la solution 1: les developpeurs gerent leur depot tout seuls, et pour les backups, tu ne fait qu'un dump. Dans ce cas, les numeros de revision (attention, different des numeros de version...) sont partages sur tout le depot
Avantage de la solution 2: tu gardes la main sur les depots, les numeros de revision ne sont pas communs a plusieurs projets; pour les sauvagardes, il faut faire plusieurs exports...

Par rapports aux differentes versions des logiciels, tu peux utiliser les commandes de fusion de SVN (porter les modifs d'une branche ou d'un logiciel vers un autre), dans ce cas, il ta faut utiliser l'option 1.

Bye