Roadmap SPIP (court terme), et Composer.
Ceci est une proposition sujette à discussion. Synthèse de discussions entre autres entre James & Marcimat.
Préambule
- SPIP 3.2, sortie le 12 octobre 2017, est compatible PHP 5.4-7.4. En tant que dernière version de la branche 3, elle est dite LTS (Long Term Support) et sera à ce titre, a priori, maintenue jusqu’en juillet 2023 (pour des patchs de sécurité seulement) : Versions maintenues - SPIP (date de fin du support de PHP 7.4 + 6 mois)
- SPIP 4.0, sortie le 8 juillet 2021, est compatible PHP 7.3-8.0.
SPIP 4.1
On souhaiterait sortir SPIP 4.1 compatible PHP 7.4-8.1 rapidement (fin janvier, début février).
Compte tenu que la date approche à grand pas, il n’y aurait pas d’autres grands travaux que cette compatibilité PHP 8.1, ainsi que la mise à jour des librairies internes, et différents petits éléments déjà intégrés.
Potentiellement quelques trucs en plus des un·es et des autres selon les disponibilités et motivations, mais rien d’énorme a priori.
Le découpage de SVP en 2 parties serait repoussé en 4.2, car ce chantier plus conséquent risque de retarder une sortie rapide d’une version SPIP compatible avec PHP 8.1.
SPIP 4.2 (juillet 2022 ?)
Si la date est respectée, SPIP4.2 resterait compatible PHP7.4-8.1 comme SPIP4.1.
Il y aurait certainement
- le découpage de SVP en 2 parties.
- le retrait de la balise état (test, stable, dev) dans les paquet.xml
au profit de la « stabilité » dans une version semver (dev, rc, beta, alpha…) (dont on déduirait un état éventuellement). L’état serait donc intégré dans le numéro de version du plugin en quelque sorte. - éventuellement, la sortie du support de ldap en plugin (ref #4648 - Sortir la gestion LDAP dans un plugin (dist ou pas) - spip - SPIP on GIT), selon la disponibilité des personnes impliquées et intéressées, en plugins-dist (ou pas dist).
- les fonctions PHP déclarées comme @deprecated devraient proposer une alternative (ou pas si la fonctionnalité est obsolète)
Un premier pas possible vers du Composer
Dans le cadre de ce second point, on introduirait une dépendance à composer/semver dans le composer.json de SPIP.
Ça voudrait dire qu’installer SPIP depuis les sources correspondrait à télécharger son git, puis lancer
composer install --no-dev (en production) ou composer install (en développement). Les zips SPIP seraient maintenus bien sûr tout comme spip_loader.
Installer SPIP depuis l’archive (spip_loader ou autre) : l’archive intégrerait un répertoire vendor/ (–no-dev) pour la version de PHP la plus petite compatible avec le SPIP (probablement sans les répertoires de tests/ ou de doc(s)/ des différents composants).
Comme config/ ou tmp/ il faut que vendor/ reçoive un .htaccess à l’installation de SPIP.
SPIP dans son fichier de chargement démarrerait l’autoloader de Composer.
On pourrait réfléchir à d’autres éléments externes à intégrer de la sorte (psr/log par exemple), et ça permettrait enfin de déclarer un autoloader (psr-4) pour les nouveaux fichiers de SPIP.
Cette introduction se veut compatible ascendante. Ce qui fonctionne en 3.2/4.0/4.1 devra fonctionner aussi en 4.2. Mais cela introduira des mécanismes compatibles avec la version suivante décrite ci-dessous.
Ainsi, SPIP4.2 serait une version LTS, comme SPIP 3.2, avec une maintenance prolongée (par exemple jusque juillet 2025, pour coïncider avec la fin de vie annoncée de PHP 8.1 fin 2024) afin de laisser le temps de migrer d’une API SPIP v3/4 à une API SPIP v5. Ici, la même logique est appliquée que pour SPIP3.2 : Date de fin du support de PHP 8.1 + 6 mois.
À voir également
- le plugin prism qui colorie la syntaxe SPIP dans l’écriture des articles. Il faudrait le tester et vérifier son bon fonctionnement.
- certainement plein d’autres envies auxquelles on n’a pas pensé.
SPIP 5.0 (janvier 2023 ?)
On peut envisager l’abandon de PHP7 pour cette version. En effet, la maintenance de PHP7.4 s’arrêtera en fin d’année 2022 et PHP8.2 devrait sortir à ce moment-là. Les premières alpha de PHP8.2 seront disponibles dès l’été 2022, et il serait intéressant d’en profiter pour tester la branche master de SPIP avec cette version.
Toutes les fonctions ou fichiers annoncés @deprecated à partir de SPIP4.0, s’ils ont une alternative proposée, devraient être supprimés. (à voir aussi pour les @deprecated 3.X qui subsistent)
Le développement de cette version se ferait en mode « composant », c’est à dire en isolant certaines fonctionnalités actuellement présentes dans ecrire/ dans des packages composer (des librairies SPIP, donc) avec le vendor « spip/ ». Ce serait la suite logique de ce qui serait fait dans la 4.2. Les premiers exemples pourraient être un composant ldap, le client http « distant », le multilinguisme, le traitement d’images, ou d’autres composants. À noter que l’externalisation d’un composant ne rend pas la fonctionnalité facultative dans une application SPIP (un composant peut être vu comme un plugins-dist) mais permet aux personnes qui le maintiennent d’isoler son développement et de le faire évoluer à un rythme différent des autres composants. Ce mode de développement permettrait aussi de mettre à disposition des « distributions » de SPIP plus variées.
Ces packages pourraient alors être testés individuellement via une CI (une plate-forme d’intégration continue qui exécute des tâches automatiquement à chaque commit/merge), que ce soit sur des questions de tests unitaires (phpunit), de qualité de code, d’analyse statique, etc. mais aussi de publication de packages versionnés en cas de succès, et potentiellement de déploiement automatique des sites de la galaxie…
Ce SPIP 5.0 utiliserait ces packages (en plus donc de librairies externes) et ceux-ci seraient publiés sur packagist.org.
C’est là où le bât blesse : Gitea (le git.spip.net actuel) ne permet pas de traiter avec packagist.org directement.
Par contre, github.com, gitlab.com ou un Gitlab autonome le permettent. De plus, Gitea ne permet pas de mettre en place l’intégration continue, contrairement à github ou gitlab.
Il sera donc impératif de réfléchir à comment et où gérer ces librairies Composer pour SPIP. Éventuellement à migrer tout ou partie (juste les nouvelles libs, ou toute l’orga « spip ») de Gitea vers un Gitlab.
Il est probablement assez peu envisageable (pas assez de temps disponible, d’humain·es) de gérer la relation avec Packagist via Satis ou d’autres outils tout en continuant à utiliser Gitea. Il est aussi peu probable que de passer par un mirroir github soit une solution perenne (ça complique encore, et les utilisatrices ou utilisateurs risquent de disperser les PR / tickets).
Enfin, notons qu’on ne discute pas ici sur comment gérer les dépendances Composer des plugins SPIP ou inversement les plugins SPIP via Composer. Cela resterait le travail de SVP dans un premier temps ou nécessitera une réflexion plus complexe le moment venu.
outro
Voilà. Dites nous les interrogations, réflexions, questions que ça vous amène. S’il y a des problèmes que cela pose, etc…
Belle journée.
