Salut,
En fait, si, le fichier changelog du répertoire aura été modifié. Pour être
plus précis :
- tu crées ton rép de travail avec les fichiers nécessaires
- tu renseignes le fichier changelog qui se trouvent parmi eux
- tu fais « Ncooker pack » qui va compléter les fichiers infos et
changelog,
_avant_ de créer le nbuild.
Donc dans ton rép, tu as à présent le fichier changelog mis à jour par la
commande pack + le nbuild.
Tu es en train de me dire que le fichier changelog de mon répertoire sera
bel et bien modifié ? Si oui, je ne suis pas d'accord dans la mesure où,
étant en train de développer mon nbuild, je suis en écriture sur le fichier
avec un éditeur de texte. Même si un "bon" éditeur de texte détecte la mise
à jour du fichier, cela ne me paraît pas propre.
Et pourquoi, dans ce cas, le fichier infos du répertoire n'est-il pas
modifié ? Je ne vois pas la différence.
Si on te demande de faire une modif, tu peux retourner dans ton rép,
incrémenter NPKG_RELEASE dans le fichier infos, ajouter une nouvelle entrée
dans le changelog, et à nouveau faire « Ncooker pack ». Tu obtiendras à
nouveau un fichier changelog mis à jour + ton nouveau nbuild.
Par contre autre cas :
tu crées un nouveau nbuild comme indiqué ci-dessus, et tu le publies. Qqn
le
récupère et le modifie, créant ainsi une deuxième release du nbuild. Puis
il
le publie. Si là on te demande de faire une modif, il faut que tu récupères
son nbuild et que tu le décompresses pour avoir les dernières modifs, dont
le
changelog.
Oui, là, c'est normal.
D'aileurs, il pourrait être sympa d'avoir une commande unpack pour
désarchiver un nbuild. Elle ferait deux choses : création d'un répertoire du
même nom que le paquet puis désarchivage des fichiers dans le nouveau
répertoire. Qu'est-ce que vous en pensez ?
Pour les nbuilds officiels, ça pourrait être bien de placer les fichiers de
conf directement sur CVS. Par fichier de conf, j'entends infos, desc,
build,
changelog, ..., par le nbuild directement.
Cette idée m'avait également éffleuré la tête. Elle pourrait permettre de
centraliser le développement des nbuilds. L'idée est à creuser.
Je pourrais aussi modifier la commande pack pour qu'elle prenne en
paramètre
une URL vers un module CVS, par exemple :
$ Ncooker pack cvs://[EMAIL PROTECTED]
ou un truc du genre ...
euh... je ne comprend pas très bien. Si on veut créer un nbuild à partir
d'un dépôt CVS, je pense qu'il faut d'abord récupérer les sources via cvs,
puis faire Ncooker pack.
> Un peu dans le même esprit, il pourrait être intéressant de trouver un
> moyen d'obliger le Nbuilder à incrémenter le numéro de version du
Nbuild.
> Je pense qu'il sera assez facile de l'oublier.
Je suis entièrement d'accord, mais comment ? :^) Pour l'instant, j'ai pas
d'idée.
Moi non plus, je n'ai pas d'idée. Je vois que tu veux mettre en oeuvre un
système pour obliger à renseigner le changelog mais il me paraît plus
important d'obliger à changer le numéro de version.
> Que se passe-t-il si je commence le développement d'un Nbuild puis je le
> passe à un autre développeur afin qu'il le fignole. Je ferai un "Ncooker
> pack" puis lui enverrai par e-mail. Il voudra reprendre le nbuild mais
la
> vérification sur l'auteur retournera une erreur. Est-ce gênant ?
Tout personne reprenant un nbuild pour le modifier, même si c'est du
fignolage, doit incrémenter le numéro de release, et donc ajouter une
nouvelle entrée dans le fichier changelog. En procédant ainsi, il n'y aura
pas de pb sur la vérification de l'auteur, puisque chacun aura travailler
sur
une release différente du même paquet.
Dans le cas dont je parlais, il s'agissait de deux personnes travaillant sur
la même release.
Gontran
--
Julien
_________________________________________________________________
MSN Messenger : personnalisez votre messagerie instantanée !
http://g.msn.fr/FR1001/866
