Salut, nouveau fil dédié à une roadmap « long terme » pour faire suite à la discussion entamée dans ce ticket.
@marcimat disait :
Il y a une discussion (probablement ailleurs) à avoir pour SPIP ‹ master › (si un des objectifs est d’aller continuellement vers un code plus objets / librairies Composer, et s’il y a des volontaires pour cela)
Je proposerais bien soit
master en 5.0.0-dev
- De passer ‹ master › en 5.0.0-dev avec pour compat minimale PHP 8.1 (dont on en sait pas trop comment elle va être cassée dans le temps)
- Éventuellement de créer une branche 4.3 (dev) si des gens veulent continuer à proposer des évolutions de SPIP compatible avec PHP 7.4 (ou pas) mais qui casserait moins le paradigme actuel.
master en 4.3.0-dev
- De laisser ‹ master › en version à peu près stable (compatibilité PHP à voir)
- De créer une branche ‹ dev › 5.0.0-dev (PHP 8.1 minimum) pour cette idée d’aller continuellement vers un code plus objets / librairies Composer…
Encore une fois ça ne fonctionnera que si des gens sont motivés un minimum ; c’est très long actuellement de créer des releases de nouvelles versions X.0 ou X.Y.0, et si on pouvait réfléchir pour aller vers un processus de gestion de cela un peu plus facile, ça serait super.
À propos des releases @marcimat disait aussi :
Il y a déjà Magraine / spip-releases · GitLab que j’adapte au fur et à mesure, mais là une partie de ce qui est long (et pas géré dans l’outil) (et par ailleurs incorrect) est de créer des branches pour chaque plugins-dist pour la release de SPIP.
C’est capilo tracté et pas vraiment nécessaire : c’est fait historiquement comme ça, et pour la 4.2, par dépit un peu j’ai continué.
Cependant il faudrait expliciter (comme dans composer.json) dans notre plugins-dist.json la version explicite à utiliser (ou ^X.Y) pour un plugins, en amont de la release, et que les plugins aient releasé des versions compatibles avec le futur SPIP, de sorte que chaque plugin (core) soit plus indépendant, et qu’une version 3.5.1 par exemple de Bidule, puisse être à la fois dans la release de SPIP 4.1 et SPIP 4.2 pourquoi pas.
Actuellement pour un tag 4.2.0-alpha par exemple, on indique explicitement dans plugins-dist.json la version (tag) du plugin à utiliser. Mais on ne le prend pas en compte, avec l’outil Checkout, si on fait
checkout spip -b4.2
(la branche), seulement avec une demande de tagcheckout spip -b4.2.0-alpha
.On pourrait avoir des plugins-dist compatibles avec le même numéro de versions avec plusieurs SPIP différents (là par exemple la compat PHP 8.2 ne cassait pas nécessairement la compat avec un SPIP plus ancien). Il pourrait y avoir des mises à jour des plugins-dist sur plusieurs versions de SPIP en même temps (tout dépend ensuite ce qu’on autorise de mettre dans une release SPIP 4.1.x par exemple — si on considère que c’est que du bugfix ou non.
Dans l’outil de release actuel, gérer le champ « compatibilité » de paquet.xml c’est un peu le bazar : c’est plus facile s’ils ont tous la même valeur actuellement, sinon il faut que je sois très vigilant pour modifier ou non correctement cette info au moment de la release du SPIP. Et c’est long (ça nécessite de la concentration disons) ça aussi dès qu’un plugin diffère…
Mais ce que je pense de ça c’est surtout : à force de chercher à faire «comme» (composer), il faudrait surtout faire «avec»… Et ça nécessite a minima un peu de rigueur aussi sur ce que sont des numéros de version semver sur les plugins au moins.
Vos avis ?