H) Gestion des releases TSP Pour l'instant je "gère" la sortie des versions pour le C et Java et les autres modules "vivent" leur vie sans gestion "réelle" des versions.H.1) TSP en C H.2) jTSP H.3) pytsp H.4) perltsp H.5) rubytsp
j'imagine qu'il faut que les modules aient toujours le numéro de la version C avec laquelle ils sont chacun compatibles ?
En fait je ne pense pas "forcement". (mais on peut en discuter) Mais chaque module doit contenir l'info et l'API pour afficher SA VERSION = jtsp v1.5.8 La version du PROTOCOLE TSP supporte = tsp proto 0x10001000 cf Pour le C: #define TSP_PROTOCOL_VERSION 0x00010001 issu de tsp_const_def.h http://cvs.savannah.nongnu.org/viewcvs/tsp/src/core/include/tsp_const_def.h?root=tsp&view=markup #define TSP_SOURCE_VERSION "@PACKAGE_VERSION@" issu de tsp_prjcfg.h.in http://cvs.savannah.nongnu.org/viewcvs/tsp/src/core/include/tsp_prjcfg.h.in?root=tsp&view=markup Pour Java: tsp.core.config.TspConfig.java private static final String JTSP_VERSION = new String("0.8.0"); public static final int PROTOCOL_VERSION = 0x00010001; http://cvs.savannah.nongnu.org/viewcvs/jtsp/src/tsp/core/config/TspConfig.java?root=tsp&view=markup
Je peux faire cela pour Ruby si tu veux (dès qu'il y a une version C avec laquelle le module Ruby fonctionne 'out of the box' ce qui ne doit pas être le cas actuellement)
Ok c'est note. -- Erk _______________________________________________ Tsp-devel mailing list Tsp-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tsp-devel
