SPIP 4.3 ?

[marcimat (Matthieu Marcillaud)]

Il semble possiblement se dessiner une petite motivation pour produire une version SPIP 4.3.
Cf: Une release 4.3 ? (#5902) · Tickets · spip / spip · GitLab

Alors questions

Quand ?

• 4.3.0 autour du 1er juillet ?
• beta autour du 15 juin ?
• alpha autour du 1er juin ?

Ou c’est trop tôt ?

Comment ?

• Créer un jalon 4.3, affecter les tickets éventuels
• Faire une branche 4.3 à partir de la 4.2
• Utiliser les mêmes branches de plugins-dist 4.2 en leur indiquant 4.* en version max
• Pour certains plugins-dist qui auraient des améliorations, nouvelle branche compat [4.3;4.*] ?

Maintenances des versions ?

Cela amène des questions sur les dates de maintenance des différentes versions de SPIP.

• On a dit qu’on ne maintenait que 2 versions (4.y, 4.y-1) et une plus LTS (la dernière 3.y, la dernière 4.y)
• On a annoncé un support de sécu 4.1 jusque fin 2024 (Versions maintenues - SPIP)
• Et la 4.2 au delà

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 …

Des avis de gens sur tout ça ?

[cy_altern]

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

[marcimat (Matthieu Marcillaud)]

@cy_altern

la 4.2 remplit assez bien le rôle de « LTS »

Heu, si une 4.3 sort, ça sera elle qui deviendrait LTS, plus la 4.2

[JamesRezo]

J’aime bien ce calendrier :

Il est inspiré de celui de PHP :

Et ce n’est pas un hasard si celui de SPIP leur ressemble :

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 ?

[JamesRezo]

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 …

[JamesRezo]

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
• Et ainsi de suite.

ça donnerait le calendrier ci-dessous :

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é.

[maieul (Maïeul Rouquette)]

ca me parait bien, sous réserve encore une fois du résultat de cette discussion SPIP 5 (et suivants) et compat des plugins - #2 par JamesRezo
car sinon cela va vite être long et complexe à suivre les montées en versions des plugins.

Mais bon quand je vois ce qui est proposé actuellement pour une 4.3

Une release 4.3 ? (#5902) · Tickets · spip / spip · GitLab

si on s’en tient à cela, il ne devrait pas y avoir de problème.

[JamesRezo]

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.

[nicod]

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.

[JamesRezo]

Yep.

Actuellement : Versions maintenues - SPIP

sur la base de l’hypothèse présentée, pour le moment, le status evoluant avec le temps :

SPIP	Status	PHP mini	PHP maxi
3.2	eol	5.4	7.4
4.0	eol	7.3	8.0
4.1	security-fix	7.4	8.1
4.2	bug-fix	7.4	8.3
4.3	dev	7.4	?
4.4	?	7.4	?
5.0*	dev	8.2	?

* : toutes les 5.X seront PHP8.2 mini et selon rythme et nombre de mineures, on étendra la borne maxi dès que possible et nécessaire

[b_b]

Ce calendrier fait rêver

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.

[marcimat (Matthieu Marcillaud)]

Faisons comme ça, alors !

[JamesRezo]

Les 12 ou 15 mois prochains mois vont être chauds …

[JamesRezo]

Jalons · spip / spip · GitLab

• La milestone 4.3 a été créée.
• 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.*]
• reste à créer la branche 4.3 dans spip/spip.

[JamesRezo]

Ok, sujet clos a priori