Edit History

@ttoine

ton message privé en réponse à des questions publique:

  Quote

hello,

Juste un message pour te dire qu'on a pas oublié de répondre à ta liste de questions dans le topic sur la 1.6.1.22, mais on a été bien chargé depuis 3 semaines. Du coup ça prend un peu de temps pour trouver toutes les réponses etc.

J'ai montré la dernière question aux devs:

  Quote

quel est le processus imaginé pour intégrer/contrôler/valider l'éco-système symfony. composer update --dry-run fait pas mal peur sur ps_facetedsearch et autoupgrade
 

Expand  

Et ça ne leur a pas paru très clair, car pour eux, Symfony et Composer sont deux sujets très différents.

Composer est utilisé pour gérer les dépendances, et Symfony est une dépendance est une dépendance parmi d'autres (même si elle est donc primordiale). A propos des deux modules que tu cites, est-ce qu'il y avait des conflits de dépendances quand tu lances la commande composer update --dry-run ? Ou bien est-ce la liste des dépendances affichées qui est un souci ? Peux-tu nous donner des précisions ou un contexte ?

Pour ps_facetedsearch, les dépendances ne s'installent qu'en dev, et il n'y a pas de dépendances en prod. Sur Auto upgrade, quelques dépendances historiques pour la prod ont été ajoutées à composer pour en faciliter la maintenance.

Expand  

Je ne sais pas trop quoi répondre à une phrase en contre-sens " Symfony et Composer sont deux sujets très différents" vs "Composer est utilisé pour gérer les dépendances, et Symfony"

C'est totalement différent ou l'un gère les dépendances de l'autre.

La question concerne la manière dont les mise à jour/dépendances Symfony sont gérable dans le cadre d'un shop actif. Comment s'assurer que les bon éléments sont présents/requis/à jour, comment mettre à jour les composants vitaux de symfony sans s'exposer à une cascade de misère. Car au cas ou cela aurait échappé à certains, le répertoire vendor est partagé entre ps, et les modules, si un module upgrade/requiert un composant symfony plus récent, ce dernier est alors mis à jour. QUID de la stabilité du coeurs, et vice et versa, comment en cas de mise à jour de sécurité requise d'un composant vendor, le coeur s'assure que les modules dépendant sont en conformité

Mais surtout sur 14 questions une seule demanderai complément d'information. Pourquoi laisser les 13 autres questions sans réponses...

@ttoine

ton message privé en réponse à des questions publique:

  Quote

hello,

Juste un message pour te dire qu'on a pas oublié de répondre à ta liste de questions dans le topic sur la 1.6.1.22, mais on a été bien chargé depuis 3 semaines. Du coup ça prend un peu de temps pour trouver toutes les réponses etc.

J'ai montré la dernière question aux devs:

  Quote

quel est le processus imaginé pour intégrer/contrôler/valider l'éco-système symfony. composer update --dry-run fait pas mal peur sur ps_facetedsearch et autoupgrade
 

Expand  

Et ça ne leur a pas paru très clair, car pour eux, Symfony et Composer sont deux sujets très différents.

" est une dépendance parmi d'autres (même si elle est donc primordiale). A propos des deux modules que tu cites, est-ce qu'il y avait des conflits de dépendances quand tu lances la commande composer update --dry-run ? Ou bien est-ce la liste des dépendances affichées qui est un souci ? Peux-tu nous donner des précisions ou un contexte ?

Pour ps_facetedsearch, les dépendances ne s'installent qu'en dev, et il n'y a pas de dépendances en prod. Sur Auto upgrade, quelques dépendances historiques pour la prod ont été ajoutées à composer pour en faciliter la maintenance.

Expand  

Je ne sais pas trop quoi répondre à une phrase en contre-sens " Symfony et Composer sont deux sujets très différents" vs "Composer est utilisé pour gérer les dépendances, et Symfony"

C'est totalement différent ou l'un gère les dépendances de l'autre.

La question concerne la manière dont les mise à jour/dépendances Symfony sont gérable dans le cadre d'un shop actif. Comment s'assurer que les bon éléments sont présents/requis/à jour, comment mettre à jour les composants vitaux de symfony sans s'exposer à une cascade de misère. Car au cas ou cela aurait échappé à certains, le répertoire vendor est partagé entre ps, et les modules, si un module upgrade/requiert un composant symfony plus récent, ce dernier est alors mis à jour. QUID de la stabilité du coeurs, et vice et versa, comment en cas de mise à jour de sécurité requise d'un composant vendor, le coeur s'assure que les modules dépendant sont en conformité

Mais surtout sur 14 questions une seule demanderai complément d'information. Pourquoi laisser les 13 autres questions sans réponses...