En releasant une 4.3, si on suit ce précepte, cela modifierait le calendrier de release, et écourterait le support annoncé de 4.1… Bref, revenir sans cesse sur ce calendrier, c’est pas terrible, surtout dans le sens d’un rétrécissement des dates de support…
En même temps, maintenir de nombreuses versions et les releaser… bah ça prend du temps aux équipes… et à celle ci notamment… et on n’a pas non plus que cela à faire ! Bref je sais pas.
Proposition, à la sortie de la 4.3, si on ne change pas (trop) le calendrier prévu actuel :
4.3 (support actif / correction de bugs jusqu’à … une date à définir)
4.2 (passe en support sécu uniquement, jusqu’à ? janvier 2026 ?)
4.1 reste en sécu jusqu’à janvier 2025 ?
Sinon on accepte de changer le calendrier… une fois de plus, et d’abandonner la 4.1 …
j’aurais tendance à penser qu’il faut rester sur 2 versions maintenues, que la 4.2 remplit assez bien le rôle de « LTS » (ce qui justifie d’autant plus d’arrêter le support de la 4.1 un peu plus tôt que prévu) et que la sortie d’une 4.3 permettant d’apporter des nouvelles fonctions semble une « compensation » largement suffisante pour ce motiver le rétrécissement du support de la 4.1
Peut-être que ça n’inspire que moi, mais ces tableaux me donne toujours envie d’avoir un cycle de release et de maintenance pour SPIP qui ressemble un peu plus à ceux de PHP et de Symfony.
Pour SPIP4.x, c’est peut-être trop tard, ou pas, ou peut-être qu’il y a un entre-deux… Mais je ne désespère pas.
Bref.
Oui pour une 4.3.0 le 1er Juillet 2024.
Oui pour créer une milestone 4.3 au plus vite. Y coller les tickets et PRs mentionnés dans le ticket 5902. Et donc, clore le ticket
Oui pour la compat’ 4.* pour les plugins-dist.
Pour cela, je suis favorable à ce qu’on fixe des dates de fin de vie, de support, etc. sur les versions maintenues et à venir.
Exemples :
Fin de vie de la 4.1 (et donc du support des correctifs de sécurité) au 1er juillet, quand on sort la 4.3
Passage en security-fix de la 4.2 au 1er juillet
Pourquoi pas fin de vie de la 4.2 lors de la sortie de SPIP5.0 ?
LTS (et security-fix) de la 4.3 jusqu’à ce qu’on envisage une date de sortie de SPIP6.0 ?
ou bien, on envisage aussi une 4.4 dès maintenant, avec sortie en janvier, ou juillet prochain ?
Si jamais il faut plus de temps, c’est décalable à l’automne, voir décembre pour embarquer la compat’ PHP8.4 aussi. Ou bien décider que la compat’ PHP8.4 ne serait qu’en SPIP4.4. On a vraiment le choix …
Voici une simulation partant de l’hypothèse suivante:
On sort une 4.3 en juillet (c’est dans 11 semaines seulement)
conséquence : on arrête le support de la 4.1 et la 4.2 passe en security-fix
On sort « en même temps » une 4.4 et la 5.0 en début d’année 2025
1ere conséquence : on arrête le support de la 4.2, la 4.3 passe en security-fix
2nde conséquence on à 3 versions à maintenir quelques mois
À partir de ce moment, la version 4.4 LTS est maintenue plus longtemps et on sort des versions mineures de la 5.x par exemple 1 fois par an
conséquence: On maintient 2 versions : 1 LTS en security-fix et une seule 5.x à la fois, mais on fait une Y+1 régulièrement. Ça permettrait d’embarquer des demandes d’évolution/amélioration plus rapidement qu’aujourd’hui, de traiter la compat’ PHP et SQL plus règulièrement, etc.
On sort une 6.0 quand on arrive au terme du cycle de vie de la 4.4 et la 5.4 devient LTS
Le rythme et les dates de sortie peuvent être discutées, le nombre de versions mineures aussi (de 0 à 2 au lieu de 0 à 4 dans cet exemple), les releases de patch mensuels seraient bien sûr, toujours d’actualité.
C’est ce que je tentai d’expliquer. Il manque des pré-requis pour que les mainteneureuses de plugins puissent avoir un bon niveau de confiance dans le cycle de vie des versions de SPIP (ou des composants qui leur sont nécessaires) pour mettre des étoiles dans leurs bornes de compatibilités : il ne suffit pas de prendre une décision, il faut aussi penser et garantir un cadre général.
L’hypothèse que je propose tente de faire la synthèse de ce qu’à dit @cy_altern, qui, je pense, exprime aussi un consensus sur le nombre de version à maintenir, les besoins des mainteneureuses de plugins et les problèmes que rencontrent les mainteneureuses de SPIP lui-même.
Il sera aussi nécessaire d’être vigilant·e·s sur le maintien de l’API de chaque version majeure, etc.
Peux tu rappeler les bornes de compatibilité PHP des différentes versions envisagées stp ?
Sur de l’hébergement institutionnel changer de version de PHP implique de changer de serveur, et c’est quelque chose à planifier plusieurs mois à l’avance.
Je pense que c’est parfait si on ajoute la proposition de @marcimat de garder la 4.1 en sécu only jusqu’à janvier 2025 pour ne pas revenir sur ce qu’on a annoncé aux gens. Même si ça implique d’avoir deux versions en sécu only sur une courte période, je pense que ça ne devrait pas trop nous charger la barque.
J’en ai profité pour expérimenté l’ajout de dates en fonction du status de la version et une description. C’est pas définitif, il reste à amender éventuellement quelques trucs et officialiser, si ça convient.
comme ces infos sont récupérables via l’api gitlab, il sera sans doute possible d’automatiser tout ou partie de la mise à jour des datas du plugin supported-versions…
les plugins-dist sont prêts avec la compat’ [4.2.0;4.*]
