Roadmap long terme, 5.0 vs 4.3

Salut, nouveau fil dédié à une roadmap « long terme » pour faire suite à la discussion entamée dans ce ticket.

@marcimat disait :

Il y a une discussion (probablement ailleurs) à avoir pour SPIP ‹ master › (si un des objectifs est d’aller continuellement vers un code plus objets / librairies Composer, et s’il y a des volontaires pour cela)

Je proposerais bien soit

master en 5.0.0-dev

  • De passer ‹ master › en 5.0.0-dev avec pour compat minimale PHP 8.1 (dont on en sait pas trop comment elle va être cassée dans le temps)
  • Éventuellement de créer une branche 4.3 (dev) si des gens veulent continuer à proposer des évolutions de SPIP compatible avec PHP 7.4 (ou pas) mais qui casserait moins le paradigme actuel.

master en 4.3.0-dev

  • De laisser ‹ master › en version à peu près stable (compatibilité PHP à voir)
  • De créer une branche ‹ dev › 5.0.0-dev (PHP 8.1 minimum) pour cette idée d’aller continuellement vers un code plus objets / librairies Composer…

Encore une fois ça ne fonctionnera que si des gens sont motivés un minimum ; c’est très long actuellement de créer des releases de nouvelles versions X.0 ou X.Y.0, et si on pouvait réfléchir pour aller vers un processus de gestion de cela un peu plus facile, ça serait super.

À propos des releases @marcimat disait aussi :

Il y a déjà Magraine / spip-releases · GitLab que j’adapte au fur et à mesure, mais là une partie de ce qui est long (et pas géré dans l’outil) (et par ailleurs incorrect) est de créer des branches pour chaque plugins-dist pour la release de SPIP.

C’est capilo tracté et pas vraiment nécessaire : c’est fait historiquement comme ça, et pour la 4.2, par dépit un peu j’ai continué.

Cependant il faudrait expliciter (comme dans composer.json) dans notre plugins-dist.json la version explicite à utiliser (ou ^X.Y) pour un plugins, en amont de la release, et que les plugins aient releasé des versions compatibles avec le futur SPIP, de sorte que chaque plugin (core) soit plus indépendant, et qu’une version 3.5.1 par exemple de Bidule, puisse être à la fois dans la release de SPIP 4.1 et SPIP 4.2 pourquoi pas.

Actuellement pour un tag 4.2.0-alpha par exemple, on indique explicitement dans plugins-dist.json la version (tag) du plugin à utiliser. Mais on ne le prend pas en compte, avec l’outil Checkout, si on fait checkout spip -b4.2 (la branche), seulement avec une demande de tag checkout spip -b4.2.0-alpha.

On pourrait avoir des plugins-dist compatibles avec le même numéro de versions avec plusieurs SPIP différents (là par exemple la compat PHP 8.2 ne cassait pas nécessairement la compat avec un SPIP plus ancien). Il pourrait y avoir des mises à jour des plugins-dist sur plusieurs versions de SPIP en même temps (tout dépend ensuite ce qu’on autorise de mettre dans une release SPIP 4.1.x par exemple — si on considère que c’est que du bugfix ou non.

Dans l’outil de release actuel, gérer le champ « compatibilité » de paquet.xml c’est un peu le bazar : c’est plus facile s’ils ont tous la même valeur actuellement, sinon il faut que je sois très vigilant pour modifier ou non correctement cette info au moment de la release du SPIP. Et c’est long (ça nécessite de la concentration disons) ça aussi dès qu’un plugin diffère…

Mais ce que je pense de ça c’est surtout : à force de chercher à faire «comme» (composer), il faudrait surtout faire «avec»… Et ça nécessite a minima un peu de rigueur aussi sur ce que sont des numéros de version semver sur les plugins au moins.

Vos avis ?

1 « J'aime »

Pour le premier point, deux branches dev me parait dangereux, déperdition d’énergie, super galère à maintenir des fonctionnalités pas forcément pareilles des deux côtés. Il me semble que c’est différent de backporter sur des branches stables ce qu’on estime sans douleur (la sécu et bugs ok et parfois petites améliorations faciles qui ne cassent rien). Mais deux « en dev » à la fois…

Par contre si SPIP 5, ça « stresse » plus dans le sens où pour un numéro majeur, il me semble qu’on se sent plus tenu d’ajouter des grosses choses qui se voient (déso mais la compat PHP les users admin-rédac et même intégrateurices, ils s’en battent les gonades à 99%). Faut prévoir que ça sera sûrement plus long à aller au bout, suivant ce qu’on veut y mettre (PAS juste PHP qui change).

Si une seule branche de dev est maintenue il me semble préférable d’accompagner le changement de compat PHP avec un changement de n°X (donc SPIP 5), même s’il n’y a pas forcément de grosses nouveautés visibles. Ça pousserait les gens à être plus vigilants avant de mettre à jour.

Compte tenu du temps à attendre que les plugins soient déclarés compatibles, je me dis que la vigilance est très secondaire en la matière…

Tout à fait d’accord avec RastaPopoulos :slight_smile:

1 « J'aime »

je plussoie largement sur ce point :

  • ça simplifierait grandement la création de nouvelles versions
  • il me semble que si ce n’est les adaptations à PHP 8, pour une majorité des plugins-dist il n’y a pas eu de changements importants depuis un bon moment…

Tu n’es pas le seul. Mais probablement pas pour les mêmes raisons. Les plugins utilisés s’adaptent très bien et rapidement aux releases. Évidemment ils ne sont pas compatibles le jour même d’une sortie, mais quand même, on est le 3 mars, et il n’y a pas eu de gros bugs avec la 4.2.0 : les principaux problèmes qui nous ont été remontés sont déjà réparés en 4.2.2…

Dans le calendrier il était question d’une 4.3 en juillet, ce qui effectivement questionne.

  • C’est bientôt. Idéalement l’essentiel du code / fonctionnalités serait fixé fin mai, pour avoir le temps de releaser et tester.
  • Incrémenter la version PHP minimale (c’était prévu cependant) sur une 4.3 n’est peut être pas pertinent. Mais pour diverses raisons, forcer PHP 8.1 minimum, apporterait tout de même un certain confort au niveau des librairies externes qu’on pourrait utiliser, de même que des simplifications dans notre code.

En discutant il y avait une mini-roadmap possible pourtant, avec un peu de motivation, de choses qui auraient pu être intégré

  • passer les fichiers de langue en return [ ... ]; (plutôt que de peupler actuellement une globale). C’est très facile car SPIP 4.1 gère déjà ce genre de fichiers ; le seul hic, c’est qu’il faut que trad.spip.net le gère aussi de son côté : c’est ça le point bloquant actuellement. Il faut up trad.spip.net en SPIP 4.2 et l’adapter pour qu’il sauve le format du fichier source principal, et écrive tous les fichiers de traductions selon se format ensuite.
  • migrer les numéros de titres des objets éditoriaux vers un champ dédié ‹ rang ›. Outre la migration de la bdd, il y aura probablement des scories ensuite sur les critères {par num titre} à gérer, ou les remplacer par {par rang}
  • refaire les squelettes DIST avec un HTML & CSS plus moderne (variables CSS, thème clair/foncé, personnalisation de la couleur principale)
  • Utiliser Monolog pour générer les logs de spip_log()

C’est à la fois petit et réalisable (quoi que la date approche rapidement), mais il n’y a rien d’indispensable non plus.

Il est aussi possible d’attendre l’année prochaine directement pour passer à une version 5.0 (sans faire de 4.3), qui pourrait aller bien au delà évidemment. Elle pour sûr elle sera PHP 8.1 minimum tel que c’est actuellement prévu.

1 « J'aime »

Le 03/03/2023 à 16:19, Matthieu Marcillaud via Discuter de SPIP a écrit :

passer les fichiers de langue en |return [ … ];| (plutôt que de peupler actuellement une globale). C’est très facile car SPIP 4.1 gère déjà ce genre de fichiers ; le seul hic, c’est qu’il faut que trad.spip.net http://trad.spip.net le gère aussi de son côté : c’est ça le point bloquant actuellement. Il faut up trad.spip.net http://trad.spip.net en SPIP 4.2 et l’adapter pour qu’il sauve le format du fichier source principal, et écrive tous les fichiers de traductions selon se format ensuite.

Mais du coup pour cette seule raison ça oblige vraiment, à ce qu’il n’y ait plus que des plugins branchés 4+ donc ? (pour être sûr de comprendre)

Puisque trad.spip ne doit pas avoir le droit de commiter ce format dans des plugins qui fonctionnent encore en 3.* (et est-ce que trad.spip sait la version des choses où il commit d’ailleurs pour discriminer ?)


RastaPopoulos

Oui et non. SPIP 4.1+ sait lire ce format (et l’ancien).

Pour mettre ce format (si tu le veux) dans trad.spip.net, oui, il faut que ton plugin soit compat SPIP 4.1+ (sinon les SPIP plus anciens, comme 3.2 ou 4.0 ne sauraient plus le lire).

Et donc, ça abonde dans le sens qu’il faut brancher plus souvent les plugins, et arrêter de publier des versions de plugins compatibles à la fois avec des branches non maintenues de SPIP tout en étant compatibles avec les branches maintenues (qui à ce jour sont la 4.1 et la 4.2). Bref, branchons les gens ! :slight_smile:

Bé c’est exactement ce que j’ai dit/demandé non ? :stuck_out_tongue:

Je disais que fallait que trad sache la version du plugin et ne le fasse QUE pour les 4+ (enfin 4.1+ tu dis mais le principe est le même) si il doit commiter le nouveau à la place, puisque sinon ça péterait les plugins qui sont multi versions quoi.


RastaPopoulos

Non non. L’idée c’était : il lit le fichier de trad source (ie lang/…_fr.php) et regarde son format, pour appliquer le même en sortie.

Coucou :wave:

On a 2 topics qui parlent de roadmap. L’un sur le « court terme » (celui-là), l’autre sur le « long terme » (celui-ci). Ils sont en commun de parler d’échéances, de dates prévisionnelles de sortie de telle ou telle version de SPIP. Je crois par contre que chaque personne qui s’implique dans cette histoire interprète les « termes » avec une grille de temps personnelle.

J’ai le sentiment que personne ne conteste aujourd’hui le fait que nous annoncions des dates de sortie pour de futures versions. Comme les réactions à ces annonces se produisent sur plusieurs canaux (irc, discuter, autre?), et dans des temps différents, c’est pratiquement impossible d’en déduire une « moyenne » ou un consensus quant au délai acceptable entre 2 releases d’importance.

Bien sûr, il y a celleux qui ne s’expriment pas, soit parce qu’iels s’accommodent du rythme, peu importe les délais, soit parce qu’iels ne font plus de mise à jour… Toutefois, parmi les personnes qui s’expriment et en simplifiant un peu, on devine 2 tendances :

  • celleux qui trouvent que ça va trop vite
  • celleux qui trouvent que ça va pas assez vite

Je pense qu’on devrait chercher à faire converger ces deux tendances avant même de parler de numéros de version et de contenu. Les aménagements et les solutions techniques pourront peut-être en découler.

Pourquoi ça va pas assez vite ?

Je crois que @marcimat a très bien résumé la situation. Je n’ai pas plus à dire à titre personnel, j’adhère, mais il y a peut-être d’autres formes de ressentis.

Pourquoi ça va trop vite ?

Essentiellement, si j’ai bien compris, parce que les plugins ne sont pas rendus compatible avant une sortie de SPIP, mais après, une fois qu’elle sort. Mais aussi en raison du support des versions PHP. Il me semble d’ailleurs que ça devient de plus en plus la raison principale…

So what ?

J’ai parlé sur IRC il y a quelques jours de la notion de « cycle de vie » et je pense que c’est la notion qui nous manque.

Nous ne nous contentons pas de sortir des versions stables. Nous annonçons des durées de vie de ces versions. Nous annonçons aussi des versions alpha et/ou beta. C’est en général, dans d’autres projets logiciels, le moment où les utilisateurs testent, mais surtout préparent, leur propres projets à la compatibilité avec la version à venir.

Dans le cadre de SPIP, un projet n’est pas seulement un ou des sites, mais aussi un ou des plugins. Et c’est peut-être là où le bas blesse :

  • Peut-être aurait-il fallu mieux expliquer à quoi ses alphas/betas sont sensées servir ?
  • Nous proposons peut-être un délai trop court entres ces « pre-releases » et les releases stables ?
  • Les mécanismes de gestions de dépendances entre spip et un plugin sont-ils suffisants pour faire ce genre de tests et de préparation ?
  • Accessoirement, on peut facilement déterminer qui sont celleux qui maintiennent encore SPIP à ce jour, mais c’est beaucoup plus flou pour déterminer qui maintient un plugin. Vu que c’est « tout le monde », il se peut qu’en fait, ce ne soit personne…
  • Enfin, petite touche personnelle, nous n’utilisons pas de mécanismes automatiques qui permettraient de tester et de rapporter les problèmes éventuels de compatibilité. Mais c’est lié aux points ci-dessus, j’imagine.

On a donc tout ça à clarifier : quels moyens ont (ou n’ont pas) les mainteneureuses de plugins pour préparer la compatibilité de leur projet avant la sortie d’une version stable ? quel est le temps nécessaire/acceptable à donner avant une resease stable ? quel est le temps de développement souhaité par celleux qui souhaitent faire évoluer le coeur de spip (avant de livrer une alpha/beta donc) ?

1 « J'aime »

Et oui, je le dis depuis des années même si je comprends la réticence de certains car il est vrai que ça peut multiplier la maintenance sauf à considérer que seule la dernière version reçoit les mises à jour et corrections (ce que je fais personnellement sur mon écosystème de plugins).

En fait, sur la roadmap spip 4 je me suis rendu compte que le travail était assez conséquent à cause de PHP et pas de spip proprement dit. Mais là c’est exact aussi que j’ai l’impression que l’on est en train de rattraper une sorte de « retard » (PHP peut être aussi) ce qui nous donne l’impression que le boulot est toujours conséquent ce que je ne crois pas, à terme.

En outre, pour revenir aux branches, les plugins qui posent problème en spip 4 ce sont ceux qui sont aussi compatibles spip 3.2 car vu la compatibilité avec PHP, ils nous empêchent de prendre en compte petit à petit les avancées de PHP. Et donc on accumule du retard qu’il faudra combler un jour.

Donc je dirais qu’une bonne pratique serait, a minima, de brancher les plugins sur des versions majeures de spip : 4, 5, 6…

Le 04/03/2023 à 08:34, JamesRezo via Discuter de SPIP a écrit :

On a donc tout ça à clarifier : quels moyens ont (ou n’ont pas) les mainteneureuses de plugins pour préparer la compatibilité de leur projet avant la sortie d’une version stable ? quel est le temps nécessaire/acceptable à donner avant une resease stable ? quel est le temps de développement souhaité par celleux qui souhaitent faire évoluer le coeur de spip (avant de livrer une alpha/beta donc) ?

Je vais donner juste, non pas mon avis, mais pratico-pratiquement ma manière de fonctionner (depuis un moment et pour longtemps encore) :

  • je ne fais presque pas de SPIP sur mon temps libre, la priorité étant être avec ma famille, surveiller les devoirs du fils, lire l’actu et des livres, faire du sport, aller à des concerts ou des manifs, je n’ai déjà pas du tout assez de temps pour faire et lire tout ce que j’aimerais, très loin de là, alors faire du code hors travail… vraiment pas la prio

  • les plugins ne sont pas à voir comme UN projet important, qui prendrait une bonne partie de notre temps à peaufiner, càd sur le modèle d’une vraie app complète basée sur un framework (par ex les mainteneurs d’API Platform basé sur Symfony etc). Dans ce cas oui, on maintient essentiellement une grosse chose, et on a un cycle de développement et de maintenance propre à notre projet précis, et on le met à jour en fonction du framework, on le bichonne etc.

  • tandis que les plugins, parfois on en a créé mille ou intervenu fortement dessus, on est « responsable » de très nombreux à la fois, et qui ne sont pas utilisé en permanence sur tous les sites qu’on touche (les trucs de commerce c’est que quelques sites, les trucs d’abonnements c’est que quelques sites, les trucs avec GIS c’est que quelques sites, etc)

  • en ce qui me concerne, je n’ai donc le temps et la possibilité de tester des plugins pour une version QUE dans le cadre où j’ai vais devoir mettre un vrai site concret à jour et qu’il utilise ces plugins, et non jamais « dans le vide », càd juste un plugin tout seul à tester hors de tout contexte précis

  • ce n’est donc jamais durant une alpha/beta que je peux savoir ça (et d’autant moins quand ça dure à peine un mois), et de ce que j’ai pu voir et ce qu’a d’ailleurs dit marcimat : la plupart des retours qu’il y a eu correspondent à la même chose : les gens ont rapporté des bugs seulement quand ils se sont mis à faire la mise à jour de leurs vrais sites dans la release finale. Même si on fait bien les choses en faisant en local d’abord etc, ça ne change rien que temporellement c’est avec la release finale, quasiment jamais durant le très court temps où ya alpha (ça ya que les gros devs qui les installent il me semble). Car nos « vrais sites », qu’ils soient associatifs ou professionnels, bah les responsables de ces sites ne prennent du temps et/ou de l’argent pour les mettre à jour que sur des vraies versions. Ya pas de jugement hein, c’est la description il me semble de comment la majorité des gens fonctionnent (et encore une fois pour insister, que ce soit associatif ou
    pro, bénévolement ou en presta, la problématique de temps est exactement la même).

Alors est-ce que les alpha/beta ne servent presque à rien du tout ? Non pas forcément, yen a toujours un peu qui arrivent à les testouiller, c’est toujours ça de pris pour avoir légèrement moins de choses à corriger après coup. Mais faut quand même pas se faire d’illusion : la majorité des bugs ou incompatibilités sont rapportés seulement après release finale, et parfois très longtemps après, par ex quand ya des plugins qui sont utilisés sur des sites très particuliers (par ex la collection tournant autour des Abonnements), et que ces sites n’ont le temps de se mettre à jour que longtemps plus tard.


RastaPopoulos

1 « J'aime »

Je pense qu’aujourd’hui la logique est bonne et la récurrence aussi.
Arrêtons de nous flageller sur le sujet on s’est assez lamenté dans les périodes où les versions se succédaient après des mois voire des années, réjouissons nous de cette nouvelle dynamique !

En outre, comme je l’ai dit dans l’autre post, je pense que le passage PHP 5 vers 7 et 8 a été un saut majeur qu’il a fallu avaler d’un coup sans y être vraiment préparé.
Je ne suis pas sur que ce soit le cas dans le futur, aussi, faut-il vraiment s’en inquiéter ?

Et puis, in fine, personne n’est obligé de migrer sur chaque version, donc où est le problème ?

Je l’avais déjà proposé dans un post Ecosystème d'une version SPIP.

Je suis convaincu qu’on peut améliorer chaque sortie en utilisant notre galaxie, à savoir, Spip, Contrib et Plugins SPIP pour tester en avance certains plugins très utilisés.
Ils sont d’ailleurs repérés par un tag et présentés ici : Plugins SPIP. Ils sont au nombre de 77.
Par exemple, on peut imaginer basculer ces sites sur les pré-releases afin de prendre le temps de faire évoluer les plugins si besoin.
De mon coté, j’ai Plugins SPIP et Contrib en local toujours branchés sur la dev de spip mais c’est exact que leur utilisation n’est pas assez intensive pour se dire que tout fonctionne : c’est là où les sites de la Galaxie peuvent être intéressants.

En outre, pour moi la seule doc qui manque c’est une sorte de digest de migration : quelles sont les manipulations à faire pour être compatible avec la nouvelle version de spip et les nouvelles versions de PHP.
Je sais bien qu’il suffit de lire quelques pages à droite ou à gauche sur le web mais une petite check-list disponible à un endroit connu ça serait pas mal.

En effet.
Il y a eu pour la 4.2 une version alpha et c’est une qualité énorme (Il me semble que ça avait manqué dans certaines précédentes releases récentes).
Un mois toutefois, c’est court.
Pour améliorer l’efficacité des préversions :

  • expliquer le rôle des préversions comme tu le suggères ET annoncer à l’avance leur date de sortie, pour que les dev-utilisateurs préparent dans leur planning, s’ils le veulent, un espace-temps pour les tester
  • augmenter la durée des préversions : 2 mois ?

On aurait donc un déroulé :

  • J-3 mois : annonce de la pré-release et de la future version (et teasing)
  • J-2 mois : pré-release et rappel des explications pour le test. Outre la dist, ce serait top si quelques autres plugins étaient « spontanément » validés comme compatibles pendant cette période…
  • J : release