AlternC/install/upgrades
Alan Garcia 83733160e5 Bugfix do_actions, happy monkey was here ! 2014-03-07 12:48:16 +00:00
..
0.9.1.sql AlternC Plugin are now part of AlternC svn repository\n Migration Phase 2 2006-04-26 12:28:53 +00:00
0.9.1_migrationldap.php Comme php5 peut etre installé, nous utilisons le lien php qui pointe soit vers php5 soit vers php4 ( soit php6 ? ). 2007-04-18 16:55:34 +00:00
0.9.2.php Comme php5 peut etre installé, nous utilisons le lien php qui pointe soit vers php5 soit vers php4 ( soit php6 ? ). 2007-04-18 16:55:34 +00:00
0.9.2.sql AlternC Plugin are now part of AlternC svn repository\n Migration Phase 2 2006-04-26 12:28:53 +00:00
0.9.3.1.sql AlternC Plugin are now part of AlternC svn repository\n Migration Phase 2 2006-04-26 12:28:53 +00:00
0.9.3.sql Merging blue desktop to trunk. 2009-09-08 05:29:38 +00:00
0.9.4.sql Merging blue desktop to trunk. 2009-09-08 05:29:38 +00:00
0.9.5.sh AlternC Plugin are now part of AlternC svn repository\n Migration Phase 2 2006-04-26 12:28:53 +00:00
0.9.5.sql Merging blue desktop to trunk. 2009-09-08 05:29:38 +00:00
0.9.6.sql Merging blue desktop to trunk. 2009-09-08 05:29:38 +00:00
0.9.7.sql remove the size_db cache, it wasn't used in the code and is fully accessible from the PHP/MySQL API 2007-08-21 00:14:13 +00:00
0.9.9.sql remove 2GB quota limitation 2008-10-06 23:27:17 +00:00
0.9.10.sql Le type des domaines passent en chaine de caracteres 2010-12-19 18:42:36 +00:00
1.0.0.sql Bug de upgrade check 2013-02-08 11:20:04 +00:00
1.0.1.php A merger avec stable 3.0 pour les fichiers 1.0.1.php et 3.0.1.php 2013-03-03 11:51:23 +00:00
1.0.3.sql Patch de 1.0.3 porté sur la 1.1 2012-08-26 11:02:46 +00:00
3.0.0~1.sql Correcting upgrade script to manage catch all aliases correctly 2014-01-31 14:33:47 +00:00
3.0.0~2.sh Updating upgrade scripts names to make sure they are executed in the correct order 2013-02-18 11:16:07 +00:00
3.0.0~3.php DEBIAN COMPLIANCE big commit : fixes almost all lintian issues + complete rewrite of debian/rules (now mostly in Makefile at the root of source code) + start using POD2MAN for man pages + remove some old unused and broken tools 2013-04-23 15:11:00 +00:00
3.0.0~4.sh fixing upgrade in 3.0.0~4 for /var/run 2013-10-18 08:01:34 +00:00
3.0.1.php A merger avec stable 3.0 pour les fichiers 1.0.1.php et 3.0.1.php 2013-03-03 11:51:23 +00:00
3.0.3~a.sql Bugfixing alias_view on upgrades ( cf Ticket #1489 ) 2013-05-02 08:12:24 +00:00
3.0.3~b.sh Fix #1500 2013-06-13 12:10:58 +00:00
3.1.0~a.sql Bugfix do_actions, happy monkey was here ! 2014-03-07 12:48:16 +00:00
3.1.0~b.php bugfixing : Populating the db_servers table while dbusers table is empty did not work. 2013-02-26 11:11:11 +00:00
3.2.1~a.sql Et si je faisait AVEC ma modif... 2013-11-06 09:41:56 +00:00
3.3.0~a.sql Bugfix do_actions, happy monkey was here ! 2014-03-07 12:48:16 +00:00
README Updating upgrade scripts names to make sure they are executed in the correct order 2013-02-18 11:16:07 +00:00

README

Fonctionnement des scripts de mise-à-jour d'AlternC
===================================================

/!\ ATTENTION /!\
Votre script DOIT etre numéroté sur trois chiffres, pas plus, pas moins.
Donc : 
 1.0.1.sql -> OK
 1.0.2~1.sql -> OK
 1.0.2~a.sql -> OK
 1.0.2.5.sql -> PAS OK
 1.0.sql -> PAS OK

Sinon, ca sera dans n'importe quel ordre.


Il a été décidé que des mises-à-jour pourront être "accrochées" à
certaines versions en les mettant dans le dossier upgrades. Lors de
l'installation d'un paquet, un script (upggrade_check.sh) examine ce
dossier et applique les mises-à-jour nécessaires, en se basant sur les
numéros de version. Les scripts considérés sont ceux terminés par
.sql, .sh ou .php, et sont interprétés avec mysql, /bin/sh ou php
respectivement, et dans cet ordre.

Pour être considéré, le script doit donc avoir un nom conforme,
c'est-à-dire sous la forme \d(\.\d+)* (en expression régulière), par
exemple: 0.9.1.sh, 1.0.php, etc. De plus, le fichier est considéré
seulement si la version avec laquelle il est nommé tombe entre la
version de départ et d'arrivée du package.
Afin de forcer les scripts d'une même version a ce lancer dans un ordre précis,
on peut rajouter ~x avant l'extension du script où x est un charctère alphanumérique
([0-9][a-z]). Par exemple pour forcer un script d'upgrade php a s'executer avant
un autre, il suffit de le rennomer X.X.X~1.php et X.X.X~2.php

Voir ci-bas pour des exemples.

Description formelle du fonctionnement de upgrade_check.sh
----------------------------------------------------------

Soit un upgrade d'une version X à une version Y. Les fichiers du
dossier d'upgrade sont examinés un à un. Pour chaque fichier dont le
nom N.php, N.sh ou N.sql est X >= N <= Y, le fichier est exécuté ou
passé à mysql, selon le cas approprié. Les versions sont comparées
avec dpkg --compare-versions.  Les scripts sont exécutés dans cet
ordre: *.sql *.sh *.php.

Il est donc capital de nommer correctement ce fichier.

Ces scripts devront être idempotents, car ils peuvent être exécutés à
plusieurs reprises, comme tous les scripts postinst et config.

(Note: en réalité, on ne vérifie pas la condition N <= Y. On assume que
si le script est disponible, il est applicable à cette version. Ceci
signifie qu'il ne faut pas "packager" un script d'upgrade N dans un
package Y si N > Y. Exemple: ne pas inclure un script 1.0 dans un
package 0.9, car il sera exécuté, même si la version installée est 1.0.)

Pour plus de détails, consultez directement le script
../upgrade_check.sh, qui gère ces upgrades.

Mise en situation
-----------------

Exemple: 0.9.1 sera exécuté lors d'une mise à jour de 0.9 à 0.9.1 (ou
1.0), mais pas d'une mise à jour de 0.9.1 à 1.0.

Autre exemple: on procède à une mise à jour de alternc-0.9-20031009 vers
alternc-0.9.1. On trouve le script upgrades/0.9.1.sh. Celui-ci est
exécuté car 0.9-20031009 >= 0.9.1 <= 0.9.1. Il serait aussi exécuté pour
une mise à jour vers 0.9.2, 1.0, etc.