(Courriels de diversion: <nier@aspergera-etaleras.com> <rime@contractualiserais-desorganisa.com> <pratiquantes@budgetaire-inconstitutionnalite.com> <mordillees@enseveliraient-assagie.com> <dispersait@aimants-soldee.com> <necrologiques@belligerante-emulee.com> <montgolfieres@deliberant-aviserai.com> <emergeriez@impartiaux-inacceptation.com> <collera@guerissable-recipiendaires.com> <coopteras@renouvellerai-sacraliser.com> )
Je me rends compte que mes dernières modifications concernant à intégrer les auto-tools dans LLiaPhon ont levé une caractéristique de l'équipe qui n'est pas gérée actuellement. En effet, le processus de génération depuis le CVS est devenu bien plus ardu : il faut maintenant disposer des utilitaires tels autoconf, automake et autoheader. Or, ces utilitaires ne concerne pas toute l'équipe. En particulier, les personnes souhaitant simplement tester la version courante du logiciel n'ont que faire de ces logiciels. Ces personnes me semblent plutôt intéressées par le tar.gz produit par le 'make dist' afin de réaliser le désormais classique './configure && make && make install'. Bref, j'ai donc jeté un oeil sur l'état de l'art vis à vis de ce problème. En fait, il semble qu'il soit classique de disposer de branches (au sens gestion de configuration) stables vouées à rester en permanence le plus stable possible et d'une branche développement accueillant les développements. Chacune de ces branches peut alors produire des releases : - pour l'utilisateur final (depuis une branche stable), - pour le testeur (depuis la branche développement), - les développeurs pouvant se synchroniser plus fréquemment avec CVS. Je pense que cette solution est bien trop complexe pour nos besoins (au moins ceux concernant LLiaPhon). J'ai donc réfléchis à une solution intermédiaire. J'introduis donc la notion de "release stable" et de "release dvelopment" sans pour autant utiliser les branches CVS. Tous nos développements sont réaliser directement sur le tronc CVS. De ce tronc, sont extraites : - des versions stables utilisant la nomenclature x.y.z, - des versions de développement utilisant la nomenclature x.y.z.AAAAMMJJ, AAAAMMJJ représentant la date courante et x.y.z représentant la version de la précédente version stable. On obtient par exemple la ligne de vie suivante : 0.3.1---0.3.1.20040721---0.3.1.20040826---0.4.0---... Voila, qu'en pensez-vous ? Voyez-vous des cas que j'aurais oublié ? -- Guilhem BONNEFILLE -=- #UIN: 15146515 -=- JID: guyou@amessage.be-= mailto:guilhem.bonnefille@laposte.netmailto:guilhem.bonnefille@free.fr-= http://nathguil.free.fr/ http://home.tele2.fr/nathguil/