[spip-dev] Notre cycle de release

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 :slight_smile:

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 :stuck_out_tongue: 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 :slight_smile:

1 J'aime

[...]

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 :slight_smile:

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

[...]

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.

Je plussois. J'espère qu'on réussira à maintenir (encore faut il commencer!) un cycle de release plus rapide… On avait espéré après la 3.2 pourtant.

Ceci dit, maintenant nous sommes en Git, et il est plus facile de faire des branches de dev, de faire des branches pour les prochaines versions, etc. Donc… avec un peu de motivation ça devrait être jouable.

Pour récapituler, voici donc des exemples de ce que cela pourrait donner en terme de versions SPIP => versions PHP compatibles.

Scénario 1 : Releases minimales

Je suis aussi très motivé pour ces propositions !

Surtout que des gros efforts ont été fait pour passer à git et le débardeur, autant en profiter !
On devrait donc pouvoir releaser plus facilement et plus proprement.

Go !

Eric

Ça me parait très bien tout ça, et assez encourageant :slight_smile:

Pour le cycle minimal / pétillant, je n'ai pas d'avis, en fait je ne sais pas (encore ?) ce qui justifierait un changement de X : composer ? réécrire SPIP en Rust ? ^^

en fait je ne sais pas (encore ?) ce qui justifierait un changement de X : composer ? réécrire SPIP en Rust ? ^^

Refonte de l'admin
Refonte d'API du core, par ex refonte de CVT
Intégration de Saisies au noyau… :smiley:

=> []