Comment structurer une application avec des multiples versions ?

Bonjour,

Je suis actuellement en train de faire une application Windows en C#, je travaille sous Visual Studio avec VSS.
Je dois cependant créer N applications à partir de celle ci.

En effet, il y aura des spécificités pour chaque application et donc un tronc commun (genre des règles fonctionnelles qui changent, des boutons en plus ou en moins, un design différent sur certains modules, ...).

J'aurais souhaité avoir vos conseils sur la question suivante :
Comment structurer mon application afin de pouvoir gérer toutes les différentes versions sans perdre mes spécificités et sans interferer non plus avec une autre application ?

Sachant qu'une application n'est jamais figée et donc que le tronc commun bougera forcemment.
je ne connais pas pour le moment quel sera le tronc commun : il va bouger petit à petit.

Merci
Worldofdada

Pour ce genre de problème, on est passé à SVN plutot que VSS. On a une branche de développement 'trunk', ensuite quand on sort une version majeure, on crée une branche pour la version majeure, et on merge les modifications du trunk, au fur et à mesure dans les autres branches. A chaque version que l'on diffuse on crée un tag des sources compilées et on archive ce tag dans un répertoire 'tag' spécifique.
Voici la structure de notre arborescence :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

| projet | | | |- trunk // Sources de développement | |- branches | | |- 1.0 | | |- 1.5 | | |- 2.0 | | |- 3.0 | |- tags | | |- 1.0 | | |- 1.1 | | |- 1.2 | | |- 1.3 | | |- 1.5 | | |- 1.6 etc

---

Merci pour cette réponse mais je ne comprends pas très bien.

Ma problématique n'est pas d'archiver correctement chaque "version" de l'application (1.1, 1.2, ...) mais chaque "édition" pour chaque version.

J'imagine notre schéma VSS de la manière suivante mais je ne vois pas comment faire pour optimiser la chose dans VSS et dans les développements.

Head
|-v1.1
| |-TOTO
| |-TATA
|-v1.2
| |-TOTO
| |-TATA
|-v1.3
| |-TOTO
| |-TATA
| |-TUTU
.....................

Mon soucis est que 90% des fonctionnalités, fenetres ... vont etre communes.
Seuls quelques points vont bouger mais je ne sais pas encore lesquels.

Si je fais une modification commune à toutes les éditions entre la 1.2 et la 1.3, je ne vois pas comment faire pour ne pas répéter la modification 3 fois (pour les 3 éditions) et ainsi de ne pas multiplier le risque d'anomalie par 3.

On fusionne les modifications du trunk dans les branches concernées, donc oui ça fait un peu de travail mais avec les scripts qui vont bien, ça marche.
Si tu crées des sources différentes pour chaque version, tu n'as pas trop le choix, il faut reporter les modifs dans chaque version à chaque fois.

ok, je vais essayer d'analyser une solution de plug in avec des dll pour chaque module qui peut avoir des spécificités.

Sinon, coté base de données, tu as une solution (il y a des nouveaux champs, nouvelles procédures stockées, ...) ?

Versionner le schéma de la base, c'est la solution que l'on a retenue.