Cette proposition « délègue » la déclaration des plugins-dist + les squelettes « dist » + prive + ecrire : en un package, on a « tout » avec une seule version (ex: composer.json · spip-project-5.x · spip / spip · GitLab)
Et du coup ça sert à quoi par rapport à les lister pareil (avec les versions etc) dans spip/spip
si de toute façon spip/spip
est la « porte d’entrée » pour ce qu’on appelle « la dist » (= la distribution officielle de base) ? Car pour installer un « SPIP classique », on passe forcément par spip/spip
.
J’ai ptet du mal à l’y retrouver dans tous ces découpages…
Tu faisais remarquer ici que les mises à jour seraient limitées par ce qui est inscrit dans le fichier composer.json
racine (celui de la porte d’entrée).
Avec create-project
, ce fichier serait, comme tu le faisais remarquer, à mettre à jour à la main par les utilisateurices.
Avec ce metapackage
, un composer update spip/classic-distribution
permet une mise à jour plus facile de la distribution (surtout dans le mode qu’on a appelé « détaché »)
Ah oui ok ça y est j’ai compris, pour quand on fait un create-project en mode « détaché » oui, et que du coup tout ce qui est à la racine n’est plus mis à jour ensuite à part manuellement.