Bonjour les ami·e·s ,
Suite à quelques messages sur le billet de blog ci-dessus, on a une décision à prendre…
Est-ce qu’on prolonge le support sur les failles de sécu pour la 4.0 jusqu’à cet été ? ou bien faut-il qu’on revienne en arrière sur le support de PHP7.3 pour la 4.1 ?
Perso, je penche pour l’extension du support pour la 4.0.
Ça donnerai en gros le calendrier suivant :
Qu’en pensez-vous ?
+1
+1 également
Et donc, la sortie de la 4.1 est à nouveau repoussée. Pour le moment de fin février au 7 mars, date complètement arbitraire qu’il sera possible de décaler encore.
Et si on décidait avant dimanche soir si on reporte la 4.1.0 à une date plus lointaine où si on la sort bientôt et quand ?
Je viens de verifier/fixer les tests et il manquait un commit de report en 4.1, c’est corrigé
Pour moi #5064 - Issues #5059 #4927 #3824 et #2109 : on reforme la logique du login - spip - SPIP on GIT est bonne à merger en 4.1 avant la release, testée dans plusieurs environnements et conditions, et en prod sur contrib.
Pas d’autre point gênant pour une release amha
Bonne nouvelle, la version 1.7 de gitea permet de gérer un repo composer 
Starting with Gitea 1.17, the Package Registry can be used as a public or private registry for common package managers.
Salut, petit état des lieux à propos de cette « envie » de roadmap.
Il faut constater qu’à ce jour on n’a pas réussi à tenir les dates qu’on s’était fixé. La sortie de la 4.2 prévue fin juillet n’a pas eu lieu, et le chantier d’introduction de composer est en pause cf https://git.spip.net/spip/spip/issues/5056#issuecomment-39959. Dans la PR en question, @marcimat propose de repousser ce chantier pour la version 5.0, dont la date de sortie est encore à fixer, perso je partage son avis.
Pour avancer tout de même, on peut se concentrer sur la future 4.X. L’idée serait de sortir une 4.2 avec une compatiblité étendue à 4 versions de PHP au lieu des 3 habituelles depuis SPIP 4, donc PHP 7.4 à PHP 8.2, au plus tard début décembre lors de la sortie de PHP 8.2. On pourra revnir à une versions de SPIP qui ne supporte que 3 versions de PHP avec la 4.3, disons 6 mois après la fin du support de PHP 7.4 (donc début juin 2023).
En lien avec le fil Aujourd'hui, quelle nouvelle version installer pour du long terme ?, pour que les plugins suivent facilement, sachant que l’écart fonctionnel entre la 4.2 et la 4.1 est très réduit à ce jour, on a deux options :
define('_DEV_VERSION_SPIP_COMPAT', '4.1.99');, qui amha n’est pas une option viable car on a souvent remarqué que ce define fait que SVP s’emmêles les pinceaux dans les calculs de dépendancesAinsi, la version 4.2 ne serait pas une version « orpheline » des plugins courants et maintenus.
À noter que cette version 4.2 apporterait en plus de la compatibilité avec PHP 8.2 l’introduction de HTML Purifier, ainsi que d’autres évolutions comme la possibilité de changer le sens de tri dans les listes d’objets cf https://git.spip.net/spip/spip/issues/4877 & le support natif d’InnoDB sans passer par un define cf https://git.spip.net/spip/spip/issues/5189 et d’autres pépites qu’on peut consulter dans le changelog https://git.spip.net/spip/spip/src/branch/master/CHANGELOG.md. Bref, ça ne serait pas une version « sans nouvelles fonctionnalités »
En parallèle, il faudrait modifier les dates annoncées sur https://www.spip.net/fr_article6500.html, pour adapter les dates de sortie annoncées et étendre le support de correctifs de sécu pour la branhce 4.0 car à ce jour elle annoncée comme hors support.
Vos avis sur tout ça ?
Hello
Je suis bon pour faire la mise à jour du serveur
Re, j’ai adapté les dates en fonction de mon dernier message, ça donnerait ceci en image :
Je peux mettre ça en ligne quelque part si nécessaire, puisque j’ai utilisé https://gitlab.com/JamesRezo/supported-versions/ comme c’est le cas sur spip.net.
Juste un détail sur la 4.1 dans ton image :
Bien vu, merci, je corrige ma PR https://gitlab.com/JamesRezo/supported-versions/-/merge_requests/18
De mon expérience de rendre compatibles pleins de plugins avec SPIP 4.1, je suis partagé :
Par ailleurs, je vois comment ça fonctionne du côté de WordPress où il n’y a pas de vérification de compatibilité au sein même de WordPress et où les plugins sont déclarés testés jusqu’à telle version et donc non testés avec les versions suivantes.
D’un point de vue développement, je trouve ça plus pratique…
Mais d’un point de vue sécurité des mises à jour, c’est un peu aléatoire.
Et voilà, c’est en prod https://www.spip.net/fr_article6500.html
Donc bon… au final on se dit que y a une 4.2 à la fin de l’année, compat de PHP 7.4 à 8.2 si je comprends bien. Ça serait bien qu’on anticipe un rétro planning, histoire que… tout n’arrive pas dedans au dernier moment… Vraiment 
(et donc ça voudra dire brancher, pour de vrai aussi).
Accessoirement «on» repousserait donc le début de Composer dans SPIP à… plus tard… c’est à dire assez loin probablement pour une 5.0… un jour. Si on trouve assez de motivation ça pourrait vouloir dire un peu plus de nettoyages / changement de code que prévu initialement.
Je propose qu’on crée la branche 4.2 le 30 septembre, soit deux mois avant la release, et que celle-ci passe en mode correctif pre-release uniquement (donc pas d’ajout).
On pourrait pas au moins finir le boulot de scindage de SVP en 4.2 ou on repousse tout en 5.0 ?
Pour la 4.2, est-ce que l’édition des logos pourrait être envisagée ?
Avec :
J’ai fait un plugin ici pour tester ça : https://git.spip.net/spip-contrib-extensions/logosplus
Avec fork complet de certains fichiers du core (spip + medias).
Peut être que tu peux faire une PR (dans spip et medias) @RealET si c’est déjà fait proprement ?
En fouillant un peu les tickets du Core, j’ai vu qu’on avait encore 3 tickets tagués 3.2, 22 tickets 4.0 et 221 tickets 4.1.
Puisque que la 4.2 sera la porte vers la 5.0 ça serait bien qu’on nettoie cette base du moins en vérifiant si le ticket est encore valide (certains semblent corrigés depuis le temps) ou si sa correction doit être reportée en 4.2 ou 5.0 voire au-delà.
Ca nous donnerait ainsi une meilleure visibilité sur le reste à faire réel.