Discussion :

[overlex]

Bonjour à tous,

Bien que tous mes développements se font en PHP (avec Zend), mon problème est plus de l'ordre de la gestion de configuration.
(Si je ne suis pas dans la bonne section, merci de m'indiquer la bonne)

Ma librairie commence à grossir considérablement, et il faut que je la découpe en modules/packages avec différentes versions.

Par contre étant donné que les modules/packages peuvent avoir des dépendances entre eux, je risque vite par exemple de me confronter au cas suivant :
ProjetA dépend du module Core v1.3 et du module Calcul v1.1, mais Calcul v1.1 dépend du module Core v1.2.

Dans ce cas là, je me retrouve bloqué car mon ProjetA a besoin des nouvelles fonctionnalités développés dans la V1.3 de Core, mais Calcul v1.1 dépend de l'ancienne version de Core (la v1.2) et si je dis à Calcul v1.1 d'utiliser Core v1.3, je risque d'avoir des incompatibilités (par ex, les définitions de fonction ne sont plus les mêmes). Sachant que je ne peux avoir bien évidemment qu'une seule version dans mon include_path.

Je pense que c'est un problème assez courant, mais impossible de trouver des informations dessus. Avez des idées ou des pistes à explorer pour gérer ce problème ?

Merci.

[gwinyam]

Une chose simple à faire, tu définis des versions globales de ton projet avec une version fixe compatible avec le reste par produit composant.

Genre :

MaGamme 1.0: Core v1.2 + Calcul v1.1
MaGamme 1.1: Core v1.3 + Calcul v1.2
Etc

L'idée étant que si tu veux utiliser la version d'un composant d'une gamme, tu te places sur toute la gamme pour tous les produits. Cela réduit les problèmes de fragmentation et de compatibilité.

[overlex]

Merci pour ta réponse, c'est vrai que c'est une bonne idée, ça apporte plus de clarté au niveau d'un projet.
Par contre cela ne résout pas mon problème, par exemple, quasiment tous les modules dépendent de Core, si Core change de version, alors je suis obligé de changer tous mes autres modules, ou moins vérifier que ca marche toujours correctement. Mais je pense qu'il n'y a pas de solution miracle par rapport à ça ?
Par contre, l'autre problème, dès que je change le fonctionnement d'un module, il faut que je regarde tous les autres modules qui dépendent de celui-ci, pour voir si ca ne pose pas de problèmes. La plupart seront gérés via les tests unitaires mais certains modules n'ont pas de tests unitaires car ils ne peuvent pas être testés via des tests unitaires. Comment lister alors ces dépendances ou quelles peuvent être les procédures à mettre en place pour être sur de ne rien oublier ou de ne pas se mélanger les pinceaux entre les versions ?

Autrement connaissez vous des articles ? des exemples ? un livre de bonnes pratiques ?

Merci encore.

[gwinyam]

On va admettre que Core est le produit clé de ta gamme de produits.

Par contre cela ne résout pas mon problème, par exemple, quasiment tous les modules dépendent de Core, si Core change de version, alors je suis obligé de changer tous mes autres modules, ou moins vérifier que ca marche toujours correctement. Mais je pense qu'il n'y a pas de solution miracle par rapport à ça ?

Si tu changes la version de Core, tu changes de gamme. Profite en pour changer les numéros de version de tes autres modules. Si pas de modif, tu fais juste une copie dans ta nouvelle branche, si des modifs, bah tu changes vraiment pour quelque chose.
En soit, ce n'est pas un souci si un module est stabilisé sur plusieurs versions de ta gamme, il faut juste que tu aies une copie de cette version dans les branches de chacune de tes versions de gamme.

Ce qui règle les problèmes de dépendance, vu que tu recopies tout. Pour les tests, normalement, chaque version de module a sa version de test. Donc ils suivent avec dans tes copies.
Et si tu ne peux pas tester unitairement, établis soit des procédures de tests visuels (j'avoue que c'est chiant comme tests), soit des tests d'intégration.

Désolé, aucune référence à fournir à part mon expérience perso et ce que j'ai appris en cours.