Nous hésitons pour la prochaine version entre une version 4.3 (PHP 8.0+) et une 5.0 (PHP 8.1+), pour quand elle sera prête (c’est pas vraiment demain, rassurez-vous)…
Petit rappel nous décidâmes un jour (pour une version n°X.Y.Z) que :
une nouvelle version de SPIP X.Y+1 ou X+1 qui sort est compatible avec les versions de PHP maintenues uniquement,
nous maintenions plus longtemps (LTS) la dernière version Y d’une branche X.
Il y a quelques points qui incitent à versionner la prochaine version 5, notamment :
le passage à PHP 8.0 ou 8.1 minimum
un projet de changement de format de «serialisation» de certaines données
un projet de «repository» Composer géré avec Satis (pour le Core et plugins-dist)
D’autre part, afin que la version de SPIP s’approche plus d’une nomenclature «semver», il conviendrait de modifier notre précédente organisation de la sorte
une nouvelle version de SPIP :
X+1 qui sort est compatible avec des versions de PHP maintenues uniquement,
X.Y+1 qui sort est compatible avec la version PHP « mini » de la version X.Y précédente
nous maintenons plus longtemps la dernière version Y d’une branche X.
Ainsi, on fait une version X+1 si :
on veux augmenter la version minimale requise de PHP
on fait un changement majeur qui casse la compatibilité
Sur ce principe,
s’il existait une version SPIP 4.3, elle resterait compatible PHP 7.4 (le PHP mini de SPIP 4.2),
sinon la 4.2 deviendrait une version LTS (conservant le support PHP 7.4 entre autres)
Est-ce que cela paraît correct ?
Quelques projets dans les cartons
Nous suggérons donc que la future version soit directement une 5.0 avec PHP 8.1 minimum.
Effectivement certains points y incitent :
L’un concerne le format de «serialisation» de certaines données, notamment, mais pas exclusivement de la table spip_meta, ce qui va casser certains usages sur des plugins lorsqu’ils ne passent pas par l’API lire_config ou ecrire_config (en lisant ou écrivant la globale directement).
L’autre concerne l’arrivée d’un «repository» Composer (généré avec Satis) pour mieux intégrer / découper / tester certaines parties du code SPIP. C’est un changement de découpage (pour le Core et les plugins-dist fournis) qui s’annonce intéressant à explorer.
D’autre part, en utilisant plus avant des librairies via Composer, nous pensons que nécessiter PHP 8.1 minimum est plus intéressant, car actuellement de nombreuses librairies requièrent cette version minimum de PHP.
Quand au calendrier, si cette 5.0 sort en début d’année 2024, cela colle avec le planning de PHP, ce que nous avions prévu, et nous laisse du temps d’expérimentations. Il n’y aurait donc pas de 4.3 en juillet.
Y a t’il des remarques ?
–
Matthieu, qui tente synthèse et compromis, suite à des échanges avec b_b, Cédric & James
Le 19/03/2023 à 09:13, Matthieu Marcillaud via Discuter de SPIP a écrit :
Quand au calendrier, si cette 5.0 sort en début d’année 2024, cela colle avec le planning de PHP, ce que nous avions prévu, et nous laisse du temps d’expérimentations. Il n’y aurait donc pas de 4.3 en juillet.
Y a t’il des remarques ?
En première lecture, moi ça me va qu’il n’y ait rien en juillet et 5.0 en 2024
Certainement. Tu pensais à quoi ? Mais y a d’autres sujets ouverts de roadmap (pas tout à fait relatifs au nommage 4.3 vs 5.0 ou PHP 8.1); je n’ai pas abordé ça ici.
Alors oui, ça serait à faire, mais non ce n’est pas nécessaire pour la partie suggérée là de sortir des librairies des plugins-dist et de SPIP). Personnellement je n’y toucherai pas tant qu’il n’y aura pas de composer.json utilisable dans les plugins-dist).
C’est un assez vaste sujet (Service de configuration spip (#5187) · Tickets · spip / spip · GitLab donc) mais qui nécessite de bien se poser. Ça amène des questions sur l’utilisation de fichiers .env, sur la structure et format des fichiers du répertoire config/, sur une syntaxe déclarative des configurations et valeurs par défaut possibles, sur la relation avec la table spip_meta et les formulaires de configuration, etc… Ça ne semble pas anecdotique.
Ça peut aussi amener d’autres sujets de conteneur de services, ou de conteneur l’injection de dépendances, et ce n’est pas si facile de faire des choix (si on ne veut pas coder et maintenir des trucs persos dans SPIP).
Ah ben j’avais compris que la 5.0 apportait ça justement. Donc je ne vois pas ce qu’on fait coté composer dans cette version.
Non ça ne l’est pas.
Mais ça serait bien d’y réfléchir voire de faire quelques PoC à minima.
Concernant les librairies composer, c’est une bonne idée de prendre quelque chose qui existe déjà mais à l’usage on voit que la maintenance n’est pas toujours au rendez-vous.
Avec Symfony, ça suit mais les autres librairies si on ne sait pas les maintenir…
Si on prend YAML pour lequel j’avais essayé plusieurs librairies, on voit que celles qui perdurent sont symfony (la nouvelle car la précédente est devenue aussi obsolète) et l’extension PHP.
Pour ma part je valide l’ensemble des propositions de Marcimat. Souffler un peu au niveau de la release du core peut aussi aider les dev de plugins (cf les autres discussions). Et nous permettre d’avoir quelque chose d’encore plus « solide » techniquement que ce vers quoi les devs du core avancent progressivement mais surement ces derniers mois. Chapeau !
Il y a un autre sujet qui me semble important : ce serait de terminer l’intégration des logos, en pouvant les visualiser/gérer dans la médiathèque.
Je ne maîtrise pas du tout ce que ça représente techniquement en terme de difficulté ni de charge de travail mais j’aurais trouvé bien que ce soit avant une 5.0. Une 4.3 avec cette finalisation de l’intégration des logos comme images « normales » me semblerait justifiée : finalisation des modifs entamées en 4.0 à ce sujet avant de passer à une version supérieure.
Et je ne vois pas pourquoi on ne ferait avec ça une 4.3 avec mini php 8.1
Top tout ça, maintenant il n’y a plus qu’à espérer que des groupes de personnes motivées vont se monter pour y ajouter quelques trucs orientées user et ça nous fera une belle release
Nous essayons de réduire la difficulté de mise à jour entre 2 versions de SPIP. Que cela concerne une personne qui met à jour globalement un site avec ou sans la présence de plugins communautaires ou pour une personne qui maintient un de ces plugins.
Il y a techniquement 2 contraintes principales : la version de SPIP elle-même et la version PHP. L’idée ici est donc de minimiser les changements dans SPIP entre 2 versions « mineures ». Les personnes qui ne souhaitent pas, ou ne peuvent pas, changer la version PHP sur leurs serveurs pourraient ainsi n’effectuer que la mise à jour SPIP vers une nouvelle version « mineures » (4.y.0) ou « patchées » (4.y.z).
À ce sujet, il ne faut pas oublier de mettre à jour James / supported-versions · GitLab pour y retirer la mention de la 4.3 une fois qu’on aura validé tout ça bien sûr
Moi j’ai quelques idées et envies de trucs orientés un peu plus end-users à proposer pour SPIP 5.
Pour certains il y a déjà des tickets ouverts, pour d’autres c’est encore un peu tôt, faut que je finisse de formuler.
Ma petite liste :
Squelettes-dist :
Thème : variables CSS, mode clair/sombre, et également coup de peinture général
Squelettes : compléments/refacto pour faciliter le theming
Espace privé / core :
Gestion générique des rangs sur toute table de liens. Autrement dit, fournir le nécessaire dans le core pour activer à la demande l’ordonnement des objets liés par glisser-déposer.
Icônes symboliques
S’attaquer à la refacto du bandeau
Corrections ou refactos diverses : sélecteur d’articles/rubriques, etc.
Ça mériterait pas un thread séparé peut-être ? Pour partager les idées des choses potentielles qu’on aurait envie de mettre dans le panier pour SPIP 5 ? Avant que ça soit traduit sous forme de tickets et jalons.
