29. Liste de vérifications pour chaque version

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

Rédigez Un sorte de plan de test standard.

Si la version a modifié un ensemble de fichiers SQL spécifiques à une version dans src/backend (par exemple si elle ajoute un nouveau fichier slony1_base.v83.sql ou slony1_funcs.v83.sql) ou si nous avons d'autres changements dans la gestion du support des versions de PostgreSQL™, la fonction load_Slony_functions() dans src/slonik/slonik.c doit être revue pour refléter le changement.

La nouvelle version doit être ajoutée dans la fonction upgradeSchema(text) située dans src/backend/slony1_funcs.sql.

Cela s'applique de manière « transversale à toutes les branches » ; 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...

Paquets RPM binaires

Si la version est une « .0 », nous devons ouvrir une nouvelle branche STABLE.

cvs tag -b REL_1_2_STABLE

Tagguez la branche avec l'identifiant de la version. Pour la version 1.1.2, cela donnerait REL_1_1_2 .

cvs tag REL_1_1_2

Récupérez une copie via cvs export -rREL_1_1_2

Exécutez autoconf pour régénérer le fichier configure à partir de configure.ac.

Purgez le répertoire autom4te.cache afin qu'il ne soit pas inclus dans la compilation.

Ceci n'a pas besoin d'être fait manuellement. Une des étapes suivantes, make distclean, le fait pour vous.

Purgez les fichiers .cvsignore ; cela peut se faire avec la commande find . -name .cvsignore | xargs rm

Ceci n'a pas besoin d'être fait manuellement. Une des étapes suivantes, make distclean, le fait pour vous.

Exécutez tools/release_checklist.sh

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.

Par exemple, le fichier configure doit contenir pour la version 1.1.2 :

PACKAGE_VERSION=REL_1_1_2

PACKAGE_STRING=slony1-engine REL_1_1_2

config.h.in doit contenir le numéro de version sous deux formes ; les définitions de SLONY_I_VERSION_STRING et SLONY_I_VERSION_STRING_DEC doivent être mises à jour.

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

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.

Ne lancez pas la commande commit sur le nouveau fichier configure ; nous ne devons pas déposer ce fichier dans le CVS.

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

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

Une commande un peu meilleure serait ./configure && make src/slon/conf-file.c src/slonik/parser.c src/slonik/scan.c

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

make distclean le fera pour vous...

Notez que make distclean efface aussi les fichiers .cvsignore et autom4te.cache, rendant du coup obsolète certaines des premières étapes qui suggéraient qu'il était utile de les supprimer.

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

Exécutez make clean dans le répertoire doc/adminguide avant de générer l'archive tar afin que bookindex.sgml ne fasse PAS partie de l'archive tar

Alternativement, vous pouvez supprimer directement le fichier doc/adminguide/bookindex.sgml.

Renommez le répertoire (par exemple - slony1-engine) avec un nom basé sur la version, par exemple - slony1-1.1.2

Générez une archive tar - tar tfvj slony1-1.1.2.tar.bz2 slony1-1.1.2

Compilez la documentation d'administration, et construisez une archive tar nommée slony1-1.1.2-html.tar.bz2.

Assurez-vous que les documents sont à l'intérieur d'un sous-répertoire d'une archive tar.

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.