Salut tout le monde,
Ça fait quelques jours que je pense envoyer ce mail pour faire suite au fil à propos de la version PHP mini, il arrive un peu tard par manque de temps....
Je pense qu'il serait vraiment bien qu'on adopte un rythme de release plus "régulier", afin de nous caler sur celui des releases de PHP, qui pour rappel est le moteur de SPIP 
Amha, on pourrait se fixer :
- une release Y chaque année, dans la même période que la release d'une nouvelle version de PHP
- moins important, mais qui permettrait plus facilement de tenir le premier point, une release Z tous les X mois (je pense à 3 ou 4).
Quelques avantages :
- on assure aux webmestres de pouvoir bénéficier d'un SPIP qui fonctionne avec les versions de PHP maintenues et à jour
- on permet aux personnes qui développent SPIP, des plugins ou des sites en SPIP, d'utiliser des librairies à jour, ou des librairies récentes qui nécessitent des versions de PHP récentes (et comme on parle d'aller vers composer qui permet de s'appuyer sur des libs externes, la question se posera aussi pour le core)
- moins de changements entre chaque version, et donc des mises à jour plus "faciles" à effectuer pour les personnes qui maintiennent des SPIP (on a moins peur de passer d'une version à une autre plus celles-ci sont rapprochées dans le temps et dont l'écart fonctionnel est moins grand)
- accessoirement, des changelog et des articles de présentation de nouvelle version bien moins chronophage à rédiger (les discussions à propos de la liste des nouveautés de la 3.3 en sont un bon exemple).
Un exemple tout frais est Nextcloud, qui pour sa dernière version (21) nécessite PHP 7.3 mini (la version 20 toujours maintenue fonctionnait en 7.2). Ce qui leur permet d'annoncer fièrement des gros gains de perfs, essentiellement dus à ceux de PHP 
Avec cette version, Nextcloud intègre la compatibilité PHP 8, ce qui donne PHP 7.3 mini / PHP 8 max.
Concernant les version mini, et toujours dans la continuité du fil à ce sujet, amha la version courante de ce nouveau cycle de release devrait se borner aux versions maintenues de PHP, cf https://www.php.net/supported-versions.php
Si on arrive à sortir la 3.3 avant novembre (je n'en doute pas et je suis plein d'espoir à ce sujet), cela donnerait :
- SPIP 3.3 compat PHP 7.3 mini
- SPIP 3.4 release en novembre/décembre 2021 compat PHP 7.4 mini
- etc
Dans tous les cas, la version maxi de PHP supportée par SPIP serait la version stable de l'année en cours, et on ne change pas de version maxi de PHP pour les anciennes releases.
Pour le premier point, pourquoi ne pas supporter PHP 7.2 dans la 3.3 ? Pour deux raisons :
- cette version n'est plus maintenue (debian buster embarque par défaut PHP 7.3, et debian stretch ne propose que PHP 7.0)
- de plus, avec tout le travail récent de reports effectué par marcimat, SPIP 3.2 fonctionne très bien avec PHP jusqu'à PHP 7.3 (comme le suggérait cedric, cette version pourra être une sorte de LTS avant ce nouveau cycle de release)
Voilà, le plan, j'espère vraiment qu'on arrive à aller vers ça, pour plein de bonnes raisons, et plein de nouvelles versions de SPIP régulièrement
