Le cas "général"
Lorsque l'on utilise un framework tel que Zend, Symfony ou encore n'importe quelle librairie, il y a deux écoles :
- Installer une fois le framework dans un répertoire spécifique. Et toutes les applications situées sur la machine utilisent cette version.
- Installer une version du framework pour chaque application.
Cependant il s'agit d'une très mauvaise idée. Vous allez en effet vous retrouver bloqué sur une version de la librairie à utiliser pour toutes vos applications. Et lorsque une nouvelle version majeure sortira et que la rétrocompatibilité avec la version précédente ne sera pas forcément très poussée, soit vous ne mettrez pas à jour. Soit vous devrez mettre à jour toutes vos applications en même temps pour faire cette mise à jour. C'est un petit peu lourd. Autant donc dire que vous ne mettrez pas à jour. Et si vous le faites, vous ne prendrez probablement pas le temps de tester chaque application correctement et vous retrouverez avec des bugs.
En revanche si vous avez une version spécifique de la librairie spécialement pour l'application, vous pouvez mettre la librairie à jour pour une application, tester celle-ci proprement et puis passer à l'application suivante.
Et en versionnant la librairie globale
Avec Rails
Rails propose quelque chose d'assez sympatique. Dans le fichier config/environment.rb, vous avezRAILS_GEM_VERSION = '2.3.2' unless defined? RAILS_GEM_VERSION
Vous définissez la version de la librairie utilisée dans l'application. A côté de cela, vous avez donc plusieurs versions de rails installées dans le répertoire des librairies globales. Et vous pouvez choisir celle que vous désirez en fonction de l'application.
Plus de librairie inclue directement dans l'application (ce qui est tout de même assez crade). Plus de problèmes de changement de version multi applications. Vous pouvez installer Rails 2.3.2 et l'utiliser dans l'une de vos applications tout en ayant toutes les autres qui tournent encore avec Rails 2.2.
Symfony
Symfony possède un fichier config/ProjectConfiguration.class.php Dans lequel vous trouverezrequire_once dirname(__FILE__).'/../lib/symfony/autoload/sfCoreAutoload.class.php';
Remplacez le chemin par celui vers la version de Symfony de votre choix. Et le tour est joué !
Zend Framework
Avec Zend Framework, c'est en définissant le include_path que vous pouvez définir la version de la librairie que vous utilisez. Si vous avez, dans votre document public/index.phpset_include_path(
APPLICATION_PATH . '/../library' . PATH_SEPARATOR
. APPLICATION_PATH . PATH_SEPARATOR
. get_include_path()
);
require_once 'Zend/Loader.php';
Zend_Loader::registerAutoload();
Il vous suffit de remplacer '/../library' par le chemin vers le dossier library versionné pour votre application.
Alors après entre utiliser des librairies versionnées et implémenter directement la version de votre choix dans l'application, c'est à vous de faire la part des choses. Je pense que cela dépends surtout des gouts. La seule chose à éviter est bien évidemment la librairie installée une seule fois, utilisée par toutes les applications et impossible à mettre à jour. Et ceci est bien évidemment faisable avec d'autres frameworks et librairies que les 3 mentionnés ici. Documentez vous ! ;)



Commentaires
Du coup tu prônes quoi en fait? Dans le cas d'une mise à jour, tu récupères la nouvelle version mais tu gardes l'ancienne en standby en cas de bug ?
Si oui, j'approuve (je crois) même si j'ai pas l'impression que ce soit si souvent que ça une source de bug. C'est plus souvent la mise à jour d'un langage qui peut faire ch*er. Un bel exemple tout bête étant la mise à jour du Zend Engine pour Windows qui casse la méthode create_element de domxml, fuckin' PHP 4 !
Je prône plutôt la dernière solution évoquée, celle qui est la plus détaillée. Mais comme dit dans le billet, seule la première est à éviter. Mettre la librairie dans l'application est également une solution envisageable.