Permalink
Switch branches/tags
Nothing to show
Find file
Fetching contributors…
Cannot retrieve contributors at this time
285 lines (239 sloc) 8.09 KB
<?xml version="1.0" encoding="UTF-8"?>
<!-- Dernière modification
le $Date$
par $Author$
révision $Revision$ -->
<sect1 id="releasechecklist">
<title>Liste de vérifications 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&nbsp;:
</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 une 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
changements 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ée dans
<filename>src/backend/slony1_funcs.sql</filename>.
</para>
<para>
Cela s'applique de manière <quote>transversale à toutes les
branches</quote>&nbsp;; si nous ajoutons une version 1.1.9 dans la
branche 1.1, alors la version 1.1.9 doit être ajoutée 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
conscientes 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&nbsp;; 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&nbsp;:
</para>
</listitem>
<listitem>
<para>PACKAGE_VERSION=REL_1_1_2</para>
</listitem>
<listitem>
<para>PACKAGE_STRING=slony1 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&nbsp;; 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
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>&nbsp;; 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>
Une méthode légèrement meilleure 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édentes qui suggéraient de les
supprimer.
</para>
</listitem>
<listitem>
<para>
Générez une archive tar HTML et RTF/PDF, si possible... Notez que la
version HTML devrait inclure les fichiers *.html (étonnant, non&nbsp;?),
*.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 l'archive tar afin
que <filename>bookindex.sgml</filename> ne fasse PAS partie de l'archive
tar
</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 une archive tar -
<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 une archive
tar nommée <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
d'une archive tar.
</para>
</listitem>
<listitem>
<para>
Placez ces archives tar 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>