Un calendrier des futures sorties

Coucou,

je fais un petit passage éclair pour revenir là-dessus :

Je pense que ce serait bien pratique d’annoncer un calendrier des sorties de versions mineures à l’avance dorénavant, maintenant qu’on sait que les sorties sont calées sur les sorties de versions PHP. Et aussi d’indiquer la « fin de vie » de ces versions aussi. Cela permettrait aux utilisateurs d’avoir une bonne idée du temps qui leur reste pour faire leur migrations et aux contributeurs/mainteneurs pour avoir une chance de planifier le boulot qu’ils ont envie/besoin de faire.

L’idée de base, c’est d’avancer en suivant PHP et d’être capable de dire ce qui va changer et quand, assez longtemps à l’avance.

À cela s’ajoute le principe de ne maintenir toujours que 2 versions majeures en même temps et une seule version mineure par version majeure à la fois.

Cf. l’exemple ci-dessous :

https://spip.lerebooteux.fr/Versions-Maintenues

Qu’en pensez-vous ?

+1 je pense qu’on peut se permettre de dire que la 4.0 n’est plus maintenue à partir du moment où la 4.1 est disponible. En effet, la 4.1 n’apportera principalement « que » la compatibilité PHP 8.1, le passage 4.0 => 4.1 sera donc transparent pour les gens. Bref, tant qu’on ne casse rien sur un saut de Y, ce calendrier est parfait, gogogo !

1 J'aime

Je suis un peu plus partagé sur un saut Y uniquement une fois par an. Mais admettons.
Qu’est-ce que tu entends par maintenir : bug fix ? security fix ?

On pourrait avoir :

  • Y+1 (dev)
  • Y, stable (bug fix + security fix)
  • Y-1 (security fix)
  • X-1 LTS (security fix)

Est-ce cela ?

Presque, sauf que je considère que la Y-1 ne doit plus être supportée tant qu’elle ne pète rien niveau compat (comme une version Y quoi…) et donc que la mise à jour vers Y stable passe sans encombre.

1 J'aime

Amha, on ne pourra jamais dire que la version Y+1 ne pète absolument rien : rien que le bump de version PHP est un problème potentiel sur les sites. Et ça voudrait dire qu’on ne fait strictement aucun changement dessus.


Si c’est le cas, par exemple pour la branche que j’ai actuellement pour les deprecated à foison sur PHP 8.1 — où j’ai ajouté certains typages à des arguments de fonctions — il faudrait que ça vienne alors dans la version X+1 de SPIP (parce que ça fait des fatales si tu appelles avec la fonction avec mauvais type, contrairement à ne pas mettre de type). Ou alors que j’enlève ces typages ajoutés, et du coup je réintroduis des tests dans les fonctions pour s’assurer de transformer les null en '' ou 0 ou false ou [] selon ce qu’on voulait dedans, pour tolérer des mauvais appels comme avant.

Alors OK, je vais peut être voir pour les retirer pour que ça ne casse rien, et trouver d’autres solutions pour ces deprecated… mais à un moment ça serait bien d’utiliser PHP un peu plus correctement…

1 J'aime

Salut les amis,

Le saut de Y était jusque là proposé sur un calque des sorties de versions PHP. Si on fait évoluer le core de SPIP plus régulièrement et de manière significative, ça devient intéressant de se détacher de PHP comme justification.

Amha, on pourra le faire et je dirai même qu’on DEVRA mettre en place des choses pour que ce soit le cas. Sur un saut de Y et encore plus sur un saut de Z :wink: : semver, si on s’en sert, ça doit servir de repères pour les utilisateurs/contributeurs/dévelppeurs. Faut qu’on soit plus stricte là-dessus.

Si on décorrèle les sorties de Y et les sorties de PHP, ça sera même plus pratique, je pense

Enfin, une des premières étapes pour rendre l’API technique de SPIP, c’est d’être plus rigoureux sur le typages des paramètres et des retours des fonctions principales du core… pas simple mais ça rendrai notre code plus prédictible.

En lien avec Proposition Roadmap SPIP (court terme), et Composer. et Mini sondage sur quelques extensions PHP >= 7.4 (zip, zlib, phar, curl)

J’ai mis à jour l’exemple qui donnerait le contenu suivant :

1 J'aime

Je trouve qu’on se traine la 3.2 vraiment longtemps encore…

C’est un calcul au doigt mouillé, donné « à titre d’exemple » (cf. Versions maintenues - #3 par cerdic)

Il n’y a effectivement pas eu de véritable décision collègiale.

L’idée derrière ce calcul, c’est d’accorder aux webmestres 6 mois après la fin du support de la version max de PHP de SPIP3.2, qui est passée de 7.3 à 7.4 lors de la dernière release (la 3.2.12, en fin d’année 2021).

ça fait 6 ans de vie pour la 3.2, alors que 3.0.0 est sortie en mai 2012 : 11 ans pour SPIP3 en tout.
avec les estimations qui sont proposées, SPIP4 vivra 4ans de la sortie de la 4.0.0 jusqu’à la fin de support acuellement proposée à mi-2025, c’est un changement radical, mais je pense que c’est un progrès.

On a tout à fait le droit de changer la date de fin de SPIP3.2 (et donc de SPIP3), en se basant sur d’autres critères ou de manière arbitraire.

Par exemple, on peut estimer que si la 4.2.0 sort en juillet 2022, on arrête alors le support de la 3.2 (-1an, dans 6 mois), les webmestres étant sans doute en mesure de passer à SPIP3.2.12, puis PHP7.4 si ce n’est fait, puis SPIP4.2 (à condition qu’on tienne l’ojectif proposé, j’imagine).

On notera que, bien que sortie depuis 1 an, seuls 1/4 environ des sites 3.2 sont à jour : Statistiques versions SPIP et plugins

Je trouve cela long aussi… (mais ça passe tout de même vite…)

C’est surtout essayer de trouver une définition pratique (fin du support de la version max du PHP (ici 7.4) + 6 mois, en l’occurrence) de la fin de notre support, qui soit assez LTS, mais pas trop long quand même pour avancer aussi…

Mais bon il faut qu’on trouve les définitions qui nous conviennent, avec aussi nos petits moyens humains derrière. Si c’est juste « = date de fin du support de la version max du PHP de ce SPIP » (sans les + 6 mois), ça me convient très bien. Et ça semble aussi bien cohérent avec PHP du coup.

1 J'aime

Ok, ça fait 3 options :

  • doigt mouillé : juillet 2023 dans 1 an et demi,
  • fin support PHP7.4: décembre 2022 dans 1 an,
  • sortie de SPIP4.2 : juillet 2022 on l’espère, dans 6 mois.

@spip-team-me d’autres avis ? sinon, on prend une décision ?

Pour ma part, je trouve cohérent de dire = date de fin de support php max.

Ce qui pour la 3.2 ferait décembre 2022. C’est très long dans ce cas, mais c’est aussi parce que l’on a pris le temps sur la 3.2 de la rendre compatible jusque PHP 7.4 alors que ce n’était pas le cas au départ. La 3.2.0 était compatible php 7.1 dont le support s’arrêtait en décembre 2020 — ce qui aurait fait 3 ans de LTS, selon ce calcul, si on n’avait rien adapté.

Mais on peut aussi noter que chez SF, les LTS c’est « 3 year support for bugs and security fixes. », ce qui au final fait moins pour la 3.2 (avec patch php 7.4) sortie en octobre 2017 (mais on n’avait pas non plus sorti de nouvelle version entre temps)

J’ai du mal à me rendre ce que ça rendra avec un cycle de release plus fréquent tel qu’on va essayer de faire (c’est à dire pour rappel au minimum 1 version par an (hors correctifs) après la sortie du nouveau PHP)

Mais puisqu’on a décidé de suivre les versions de PHP maintenues, ça me parait un bon critère de décision de dire si SPIP X.Y LTS est compatible jusqu’à PHP X.Y, alors on le maintient (sécurity fix surtout) jusqu’à la fin de support de PHP X.Y.

D’autres avis ?

Il faut juste qu’on ait pas trop de LTS en même temps ; et aussi dire peut être que c’est un engagement de principe (ie: on fera au mieux, y a pas de garantie…)

ok, je vote pour décembre 2022 aussi. et +1 sur l’engagement de principe.

Je reste sur ma position que c’est trop long pour la 3.2 mais je me plierais à la décision si c’est celle-là qui est prise.

Je ne serais pas contre le fait que tu développes un peu :slight_smile:

+1

1 J'aime

A voté :smiling_imp: