Perso, je trouve qu’on est en plein dedans.
Mais c’est vrai qu’au départ, on parlait des simplifications qu’on pourrait mettre en place pour la création de releases en général : gestion des dépendances, outils, CI/CD … Je me plante peut-être, mais de cet ensemble, une question fondamentale, c’est la gestion des dépendances … qui n’est pas « maîtrisée » par toute l’équipe…
Il faut bien comprendre qu’à partir de SPIP5, c’est par composer que ça passe :
- C’est avec ça qu’on produit les zips de SPIP5.
- Avant (et donc, encore aujourd"hui pour les 4.x), on « bricole » un
plugins-dist.json
et il y a toujours la gestion des plugins de SPIP (+SVP) qui check l’attribut compatibilite
, les necessite
, etc. du paquet.xml.
- La compat spip/plugins-dist via composer pourrait être améliorée, mais actuellement, on pourrait très bien se passer de la vérification de la compat des plugins-dist …
- On a de vieux topics sur le fait de rendre facultatif les attributs version/etat/compatibilite. On pourrait remettre ça sur le tapis. On les enlèverait des plugins-dist mais ça marcherait pour les contribs … par exemple.
Je dis depuis un certain temps qu’on peut assez facilement passer à composer pour les versions d’avant la 5 pour les plugins-dist. Uiliser une seule technique pour toutes les versions maintenues, ce serait déjà un plus … on s’épargnerait quelques commits lors des releases mensuelles.
Et donc, au final, qu’un plugin-dist suive le cycle de vie de SPIP ou pas peut se décider au cas par cas. le squelettes-dist
pourrait être sur les mêmes versions X.Y
que SPIP par exemple, l’écran de sécu à son propre cycle depuis longtemps, … certains plugins-dist n’ont pas la moindre dépendance à l’API de SPIP, et c’est beaucoup plus logique qu’ils aient leur propre rythme de version.
Bref, s’il le faut, diversifions les topics, mais de toute manière, il y a une grosse imbrication des enjeux et du code qu’il faut démêler comme un ensemble.