root/traduc/trunk/slony/releasechecklist.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- DerniÚre modification
     le       $Date$
     par      $Author$
     révision $Revision$ -->

<sect1 id="releasechecklist"> <title>Liste de vérification pour chaque version</title>

<indexterm><primary>Liste de vérifications pour chaque version</primary></indexterm>

<para> Voici les choses qui devraient être faites avant la sortie de chaque version :</para>
<itemizedlist>

<listitem><para>Compilez avec succÚs sur chaque plate-forme supportée -
bien que cela soit moins nécessaire lorsque l'on publie une version mineure.
 </para></listitem>

<listitem><para>Rédigez Un sorte de Plan de Test Standard</para></listitem> 

<listitem><para> Si la version a modifié un ensemble de fichiers SQL spécifiques
    Ã  une version dans <filename>src/backend</filename> ( par exemple : 
    si elle ajoute un nouveau fichier <filename>slony1_base.v83.sql</filename> ou
<filename>slony1_funcs.v83.sql</filename>), ou si nous avons d'autres changement
dans la gestion du support des versions de &postgres;, la fonction  
<function>load_Slony_functions() </function> dans
<filename>src/slonik/slonik.c</filename> doit être revue pour refléter
le changement.</para> </listitem>

<listitem><para> La nouvelle version doit être ajoutée dans la fonction
<function>upgradeSchema(text)</function> situé dans
<filename>src/backend/slony1_funcs.sql</filename>. </para>

<para> Cela s'applique de maniÚre <quote>transversale à toutes les branches</quote>;
si nous ajoutons une version 1.1.9 dans la branche 1.1, alors la version 1.1.9 doit 
être ajoutées dans la branche 1.2 ainsi que dans les branches ultérieures ( par exemple :
1.3, 1.4, HEAD). Normalement les branches postérieures n'ont pas besoin d'être consciente
des versions ajoutées dans les branches ultérieures...</para> </listitem>

<listitem><para>Paquets RPM binaires</para></listitem> 

<listitem> <para>Si la version est une <quote>.0</quote>, nous devons ouvrir une
    nouvelle branche STABLE.</para>

<para> <command> cvs tag -b REL_1_2_STABLE</command></para> </listitem>

<listitem> <para>Tagguez la branche avec l'identifiant de la version. Pour la version 1.1.2, cela donnerait
    <envar>REL_1_1_2 </envar></para>

<para> <command> cvs tag REL_1_1_2 </command></para> </listitem>

<listitem><para>Récupérez une copie via <command>cvs export -rREL_1_1_2
</command> </para></listitem>

<listitem><para>Exécutez <application>autoconf</application> pour régénérer le fichier 
<filename>configure</filename> Ã  partir de 
<filename>configure.ac</filename></para></listitem> 

<listitem><para>Purgez le répertoire <filename>autom4te.cache</filename> afin qu'il ne soit pas inclus
    dans la compilation</para>
<para> Il n'est pas nécessaire de le faire à la main - la commande suivante <command> make distclean </command>
  le fait pour vous. </para>
</listitem> 

<listitem><para>Purgez les fichiers .cvsignore; cela peut se faire avec la commande
    <command> find . -name .cvsignore | xargs rm </command>  </para>
<para> Il n'est pas nécessaire de le faire à la main - la commande suivante <command> make distclean </command>
  le fait pour vous. </para></listitem> 

<listitem><para> Exécutez <filename>tools/release_checklist.sh</filename> </para>

<para> Cela effectue une série de test de cohérence pour s'assurer 
  que les différents fichiers qui sont supposés contenir les numéros de versions
  contiennent des valeurs cohérentes.</para> 
</listitem>
<listitem><para>Par exemple, le fichier configure doit contenir pour la version 1.1.2:</para></listitem>

<listitem><para>PACKAGE_VERSION=REL_1_1_2</para></listitem>

<listitem><para>PACKAGE_STRING=postgresql-slony1-engine REL_1_1_2</para></listitem>

</itemizedlist>
<itemizedlist>
<listitem><para> <filename> config.h.in </filename> doit contenir le numéro de version 
    sous deux formes; les définitions de 
<envar>SLONY_I_VERSION_STRING</envar> et
<envar>SLONY_I_VERSION_STRING_DEC</envar> doivent être mises à jour. </para> </listitem>

<listitem><para> <filename>src/backend/slony1_funcs.sql</filename> a les numéros de version 
    de majeure/mineure/patch dans les fonctions 
<function>slonyVersionMajor()</function>,
<function>slonyVersionMinor()</function>, et
<function>slonyVersionPatchlevel()</function>. Jusqu'à maintenant, cela doit être 
modifié <quote>à la main</quote>.</para> </listitem>

<listitem><para> Bien sûr il serait agréable si une partie de ces opérations
    pouvaient être effectuées automatiquement, d'une façon ou d'une autre.</para>

<para><emphasis>Ne lancez pas</emphasis> la commande  <command>commit</command> sur 
  le nouveau fichier <filename>configure</filename>; nous ne devons pas 
  déposer ce fichier dans le CVS.
</para></listitem>

<listitem><para>Assurez-vous que les fichiers générés à partir des .l and .y sont bien créés
    , par exemple <filename>slony/conf-file.[ch]</filename> </para>

<para>Pour le moment, la meilleure solution pour le faire consiste à exécuter <command> ./configure &amp;&amp;
make all &amp;&amp; make clean</command> mais c'est une approche quelque peu disgracieuse.

</para>
<para> Un méthode légÚre meilleur consiste à lancer <command> ./configure &amp;&amp; make
src/slon/conf-file.c src/slonik/parser.c src/slonik/scan.c </command>
</para>

</listitem> 

<listitem><para> Assurez-vous que les Makefiles et autres fichiers générés lors des étapes 
    précédentes ont été supprimés.</para>

<para> <command>make distclean</command> le fera pour vous... </para>

<para> Notez que <command>make distclean</command> nettoie aussi les fichiers
  <filename>.cvsignore</filename> et 
<filename>autom4te.cache</filename>, rendant ainsi obsolÚte les étapes précédantes
qui suggéraient de les supprimer. </para>
</listitem>

<listitem><para>Générez une archive tarball HTML, et RTF/PDF, si 
possible... Notez que la version HTML devrait inclure les fichiers *.html (étonnant, non?),
*.jpg, *.png, ainsi que *.css </para></listitem>

<listitem><para>Exécutez <command>make clean</command> dans le répertoire
<filename>doc/adminguide</filename> avant de générer le tarball afin que 
<filename>bookindex.sgml</filename> ne fasse PAS partie du tarball </para></listitem>

<listitem><para>Alternativement, vous pouvez supprimer directement le fichier
<filename>doc/adminguide/bookindex.sgml </filename> </para></listitem>

<listitem><para>Renommez le répertoire (<emphasis>par exemple</emphasis> -
<filename>slony1-engine</filename>) avec un nom basé sur la version,
<emphasis>par exemple</emphasis> - <filename>slony1-1.1.2</filename>
</para></listitem>

<listitem><para>Générez un tarball - <command>tar tfvj
slony1-1.1.2.tar.bz2 slony1-1.1.2 </command> </para></listitem>

<listitem><para>Compilez la documentation d'administration, et construisez un
    tarball nommé <filename>slony1-1.1.2-html.tar.bz2</filename></para>

<para> Assurez-vous que les documents sont à l'intérieur d'un sous-répertoire du tarball.
</para></listitem>

<listitem><para>Placez ces tarballs dans une zone temporaire, et informez tout le monde
    qu'il faut les tester aussitÃŽt que possible en suivant le Plan de Test Standard.
     </para></listitem>

</itemizedlist>
</sect1>