Oui, je peux.
Mais avant, j’aurais aimé avoir des retours sur les choix que j’ai pu faire.
J’ai testé logoplus avec succès sur le logo d’un article sur un SPIP 4.2 (après élargissement de la compat déclarée dans paquet.xml).
Ça apporte un réel plus en rapprochant le traitement des logos de celui des documents.
De ce test il est resté 2 tickets : https://git.spip.net/spip-contrib-extensions/logosplus/issues
1 « J'aime »
Si on pense que c’est possible d’ici fin septembre, oui, sinon on repoussera pour la 4.3 par exemple.
Je pense qu’on peut déjà acter que tous les tickets tagués « amélioration » devraient être déplacés sur la branche active du moment, donc la 4.1 ou plus.
De même, toutes les branches dont le support ne concerne que les correctifs de sécu (inférieur à 4.1 donc) ne devraient plus comporter de ticket tagué « bug », à moins que le fix soit facilement reportable dans celles-ci si on souhaite être « plus souples ».
+1
PS : j’ai fermé et marqué comme wontfix/refusé un des 3 tickets concernant la 3.2.
J’ai commencé le ménage, il ne reste plus que 4 tickets ouverts sur la 4.0, j’attends des retours dans les commentaires de ceux-ci pour décider de ce qu’on va en faire. J’attaque ceux de la 4.1 dès que possible.
Voilà, j’ai pris « un moment » pour faire le ménage dans les tickets des plugins-dist, Je vous laisse consulter la page de suivi de l’activité de git.spip pour voir les changements effectués.
Je pense qu’on est pas mal maintenant, il ne reste plus qu’à vous motiver pour proposer des correctifs pour tout ça 
3 « J'aime »
Yop, une question à l’approche de la date de « feature freeze » de la 4.2…
Après mûres réflexions, avec @marcimat on se dit qu’il serait intéressant d’intégrer la PR du chantier d’introduction de composer dans la 4.2 cf https://git.spip.net/spip/spip/pulls/5057. L’idée est d’avancer sur le sujet et cela éviterait à @marcimat d’avoir à maintenir cette PR (chose qu’il fait déjà depuis des mois) pour la garder synchro avec les évolutions de SPIP. Cela permettrait en plus de corriger certains bug en rapport avec la compatibilité PHP 8.2, comme https://git.spip.net/spip/spip/issues/5292 à propos des fonctions utf8_encode/ utf8_decode qui sont dépréciées.
À noter, cette branche de SPIP est utilisée au quotidien par @marcimat et il nous resterait encore deux mois pour la tester à plus grande échelle.
Techniquement, cela ne changerait rien pour les personnes qui installent SPIP avec spip_loader ou à partir du zip, et les outils qui permettent aux devs de récupérer SPIP en git prendraient en charge automatiquement l’étape composer install cf https://git.spip.net/spip-contrib-outils/checkout/pulls/6
Qu’en pensez-vous ? On merge, on ne merge pas ?
1 « J'aime »
Dans ce contexte je dis gogogogo
1 « J'aime »
+1
1 « J'aime »
+1
Si ça peut commencer à avancer vers Composer tout en conservant le fonctionnement actuel pour une transition en douceur (oui, je paraphrase 
), c’est le meilleur des 2 mondes donc gogogo !
1 « J'aime »
Si ça ne change rien pour spip_loader et que c’est l’avenir pour SPIP, mais qu’il y a un risque significatif de ratage dans la version initiale avec ce début de Composer, alors il faut peut être sortir une Béta pour commencer.
Ceci devrait répondre à ta question 
Techniquement, cela ne changerait rien pour les personnes qui installent SPIP avec spip_loader ou à partir du zip, et les outils qui permettent aux devs de récupérer SPIP en git prendraient en charge automatiquement l’étape
composer installcf https://git.spip.net/spip-contrib-outils/checkout/pulls/6
d’autant plus qu’une bonne partie (la majorité ?) des utilisateurs qui récupèrent SPIP en git le font via checkout ou spip-cli, cad avec déja du Composer « dans le moteur »…
Qu’en pensez-vous ? On merge, on ne merge pas ?
oui !
1 « J'aime »
Je suis aussi favorable à la fusion, surtout si c’est transparent
Pour info, puisque tout est permis le vendredi (non ?), c’est enfin intégré \o/
3 « J'aime »
Coucou, faute de disponibilité de @marcimat et ma part on a pris du retard pour la release des pré-versions de la 4.2 ce qui nous oblige à revoir le calendrier.
Si ça vous va , je propose de décaler tout ça ainsi :
- sortie d’une pré-version de la 4.2 (alpha+beta, ou uniquement une RC) au 10 janvier 2023
- sortie de la version stable de la 4.2 au 10 février 2023
- décalage des dates de fin de support actif et sécu des autres versions en conséquence
Ce qui donne le diff suivant pour le fichier data/releases.json · master · James / supported-versions · GitLab
diff --git a/data/releases.json b/data/releases.json
index df824b7..cdb572a 100644
--- a/data/releases.json
+++ b/data/releases.json
@@ -2463,7 +2463,7 @@
"branch": "3.2",
"initial_release": "2017-10-12 09:13:02",
"active_support": "2021-07-09",
- "eol": "2022-12-31",
+ "eol": "2023-02-10",
"last_version_release": "3.2.16",
"last_date_release": "2022-07-21 11:55:58",
"technologies": {
@@ -2804,7 +2804,7 @@
"branch": "4.0",
"initial_release": "2021-07-08",
"active_support": "2022-03-31",
- "eol": "2022-12-31",
+ "eol": "2023-02-10",
"last_version_release": "4.0.8",
"last_date_release": "2022-07-21 11:44:26",
"technologies": {
@@ -3019,8 +3019,8 @@
{
"branch": "4.1",
"initial_release": "2022-03-25",
- "active_support": "2022-12-31",
- "eol": "2023-06-01",
+ "active_support": "2023-02-10",
+ "eol": "2023-08-10",
"last_version_release": "4.1.5",
"last_date_release": "2022-07-21 17:39:45",
"technologies": {
@@ -3191,9 +3191,9 @@
},
{
"branch": "4.2",
- "initial_release": "2022-11-30",
- "active_support": "2023-05-31",
- "eol": "2024-12-31",
+ "initial_release": "2023-02-10",
+ "active_support": "2023-07-10",
+ "eol": "2025-02-10",
"last_version_release": "",
"last_date_release": "",
"technologies": {
@@ -3260,8 +3260,8 @@
},
{
"branch": "4.3",
- "initial_release": "2023-06-01",
- "active_support": "2023-12-01",
+ "initial_release": "2023-07-11",
+ "active_support": "2024-01-10",
"eol": "",
"last_version_release": "",
"last_date_release": "",
@@ -3294,7 +3294,7 @@
},
{
"branch": "5.0",
- "initial_release": "2023-12-01",
+ "initial_release": "2024-01-10",
"active_support": "",
"eol": "",
"last_version_release": "",
2 « J'aime »
Oui. Décalons les dates pour releaser tranquillement et sortir une belle SPIP 4.2
Compte tenu du temps qu’il a fallu pour déclarer/adapter les plugins à SPIP 4.1, je m’interroge sur la pertinence de 2 releases par an.
Déjà, une par an, c’est chaud pour suivre (rendu cependant nécessaire par le rythme de PHP).
Mais 2…
À moins :
- de changer la manière dont la compatibilité des plugins est gérée (genre à la WP : n’a pas été testé, mais on peut installer à ses risques et périls)
- ou de faire conjointement aux ruptures de compatibilité une branche à merger pour chaque plugin touché par cette rupture (on peut rêver, hein…)
1 « J'aime »