SPIP 5 (et suivants) et compat des plugins

Pour SPIP 5, et en prévision des modifs de plugins à faire, on n’a pas répondu explicitement à ma question du fil précédent (mais qui était initiée par une proposition de @marcimat un peu au dessus)

qui est de savoir si à partir de SPIP 5, on considère ou pas qu’on a atteint un niveau de sérieux dans le semver suffisant pour pouvoir dire que par défaut les plugins peuvent indiquer une compatibilité sur la branche X entière 5.*.

Et je dis bien :

  1. c’est une vraie question, pas rhétorique, donc si on considère que non, on continue comme avant hein, mais si vraiment on considère que oui, c’est tout bénéf pour tout le monde (les devs et les utilisateurices) ; je ne tiens pas à ce qu’on réponde oui absolument, je tiens à savoir si c’est le cas ou pas, car si oui c’est un gros bénéfice qui rend la vie plus simple pour beaucoup de monde différent
  2. « par défaut », donc ça serait le cas général, ce qui n’empêche pas d’avoir tel ou tel plugin qui continuent d’avoir un compat max X.Y.* seulement (en gros on inverserait le cas général et le cas particulier par rapport à maintenant)

Sachant pour rappel que :

  • si on suit vraiment semver assez sérieusement (à nous de déterminer si oui ou non donc) ça ne devrait pas poser de problème majeur
  • c’est une pratique courante dans plein de paquets composer (c’est ^X chez eux)
  • plus proche de nous c’est pratiqué dans de gros CMS et pour des gros plugins pas du tout comme « NoSpam », genre Drupal Commerce qui est complexe, qui indique une compatibilité pour tout Drupal 9 (^9 chez eux)

Et pour parler en chiffres exacts et pas en théorique, cela signifie dire que SPIP 5.1 ne fera QUE ajouter des fonctionnalités sans rien casser du tout du tout des précédentes fonctions. Et pareil pour 5.2 ensuite etc.

2 « J'aime »

Oui, c’est ce qu’on explique depuis quelques années @rastapopoulos . Rien de nouveau sous le soleil, donc. :slight_smile:

euh rien de nouveau quoi ? C’est justement parfaitement nouveau puisque ce n’est pas ce qui se fait actuellement, et puisque ça ne peut se faire non pas « si on explique que ça pourrait être bien », mais seulement si on considère que c’est réellement le cas à partir de maintenant, qu’on est réellement assez carré pour documenter que c’est ça la base maintenant (et donc faut répondre oui ou non explicitement).

Par ailleurs c’est d’autant moins « rien de nouveau » que dans le fil précédent Cédric était parfaitement opposé à ça et argumentait contre. Donc la question est bien légitime à poser et surtout à y répondre clairement pour SPIP 5. :slight_smile:

J’ai suivi l’échange en question, et je l’ai compris différemment. De ce que j’ai compris, c’est que Cédric était contre rajouter quelque chose (la fonction svg_img…) dans la 4.2 ce qui compliquerait la documentation. Mais qu’il était pour le faire dans une 4.3. Et que la solution la plus simple était de créer un plugin de transition (comme bigup existe en 3.2, et est natif 4.0, ou plein de fonctions disponibles dans Bonux)

Même pas vrai ! Non sur ce point c’est moi qui disait cela, mais vous ne parlez pas de la même chose il me semble. Rasta parle des bornes max des plugins sur 4.* par exemple, où Cédric était retissant ; En tout cas c’est c’est ce que j’ai compris en lisant en diagonale :slight_smile:

Si, au lieu de parler en son nom, vous le laissiez s’exprimer (ou demandiez de re-préciser…) ?

1 « J'aime »

/me mange du popcorn

1 « J'aime »

Bah j’ai donné le lien du fil hein…

Une nouvelle règle « par principe » de déclarer les plugins compat 4.x pour faciliter le travail des dev et éviter que les utilisateurs doivent attendre pour faire les mises à jour, c’est tout aussi mauvais (et même plus selon moi) : ça veut dire que les utilisateurs ils vont mettre à jour et leur site va casser car un ou des plugins ne seront pas compatibles.

Le fil de réponses partant du principe que je voulais absolument déclarer que c’était possible de faire ça, alors que précisément ma question est, je le répète : est-ce qu’on est réellement désormais assez ok avec semver pour affirmer et documenter que par défaut les plugins peuvent être compat X.*, et inversement seulement exceptionnellement X.Y.* pour quelques cas ?

Et que si c’est vraiment oui, alors là bah oui faut le faire, c’est super pour tout le monde, ça facilite les devs, et ça facilite les users qui n’ont plus à attendre mille ans à chaque version de Y pour que tous les plugins soient ok (et donc ça augmente massivement la quantité de sites pouvant être mis à jour vite, sans retard).

1 « J'aime »

Je ne sais pas de quoi tu parles, tu t’es pas trompé de fil ? :stuck_out_tongue:
On parle de la possibilité de compat X.* (comme règle courante par défaut) des plugins ici.

1 « J'aime »

Personnellement je repete ce que j’avais dit il y a quelques mois

  1. C’est plus simple pour tout le monde si on suit vraiment du semver
  2. On commence à le suivre vraiment, même si on a eu quelques cas entre la 4.0 et la 4.2 qui ont cassé, notamment sur le codage/decodage des modèles qui sont passés d’une globale à des objets, ce qui peut casser les plugins qui s’appuyaient dessus
  3. Pour autant je pense que si on est attentif à bien montrer ce genre de choses dans les CHANGELOG et autre README et si en plus on essaie de les éviter, et bien c’est jouable.
3 « J'aime »

C’est qui ce « on » ? :wink:

Tu parles de compat’ gérée avec les fichiers paquet.xml .

SPIP5, ce n’est pas que les paquet.xml, même si c’est important…

Et, moi, je n’ai fait que rappeler que certains d’entre-nous parlent du sujet, plus vaste, certes, de la gestion des dépendances depuis un moment, avec toute la transparence qu’il est possible d’y mettre, en réduisant les aspects « techniques » au minimum possible. Mais surtout en incluant les fichiers paquet.xml dans nos discussions.

Certes, la communauté SPIP, au sens large, ne s’approprie pas ce sujet autant que nous aurions pu le souhaiter. Dont acte. Pour autant, est-ce que cela en fait un aspect négligeable de la question ?

En réduisant le sujet aux seuls paquet.xml, cela nous fait, selon moi, passer à coté de solutions comme tu les aimes : génériques, extensibles ou personnalisables, prometteuses de nouvelles possibilités.

Donc, non, ce n’est pas nouveau. C’est bel et bien ce qui se fait actuellement, dans une mesure qui ne casse pas la prise en compte des paquet.xml.

Au delà de la simple explication, nos efforts sur les releases depuis SPIP4.0, d’affichage des versions maintenues et des configuration requises sur spip.net sont documentées, effectives et, c’est osé, mais tant pis, démontrées.

Que tu t’intéresses désormais au sujet, plus ou moins partiellement, est positif, et tes questions sont légitimes à ce titre.

Je t’invite plutôt à nous rejoindre en tenant compte de ce que nous avons réalisé depuis 2018.

Je ne comprends pas ta réponse tout en circonvolutions. Ma question est bien plus prosaïque, et ne s’occupe pas spécialement de comment fonctionnent les dépendances (que ce soit paquet.xml ou composer, ne change pas fondamentalement la question, cf l’exemple de Drupal Commerce qui est un gros plugin de gros CMS, en composer) :

  • SPIP 5 est certes un peu repoussé, mais arrive concrètement dans quelques mois
  • en prévoyant en avance et non pas au moment de la sortie ce questionnement de compat des plugins
  • au regard des dernières sorties de SPIP 4, puis de ce qui est prévu pour SPIP 5.Y à l’avenir, et de ce qu’on fait attention à mettre ou pas dedans
  • est-ce qu’on est désormais assez carré sur semver pour dire que les plugins peuvent majoritairement (peu importe qu’il y ait toujours quelques exceptions) être compatibles sur une branche X, et non plus sur une branche Y comme maintenant ?

Je ne vois pas le rapport avec rejoindre ci ou ça, je parle de documentation/recommandation par défaut, à indiquer à celleux qui maintiennent des plugins, pour les mois qui arrivent là à relativement court terme.

En partant du principe que c’est de mieux en mieux, est-ce qu’on pense que 5.1, 5.2 etc ne vont rien casser de majeur, et que dès la prochaine version du core (5.0) la plupart des plugins (obliger de préciser qu’il peut y avoir des exceptions partout même si ça devrait être évident), pourront être mis en borne max 5.* (ou ^5 peu importe) ?

C’est une question fermée booléenne (oui ou non), s’il y a le moindre doute trop important, alors la plupart des plugins seront en borne 5.0.* et faudra tous les revérifier pour SPIP 5.1 et donc la réponse serait « non ». C’est si complexe que ça à répondre ? @maieul a répondu plus simplement son avis du moment :stuck_out_tongue:

Bon. ça ne marche pas non plus comme approche…

Tantôt « trop cash », tantôt « trop précautionneux », jamais comme il faut en somme…

Au moins, j’aurais essayé.
J’essaierai peut-être d’une encore autre manière, plus tard.

Ce n’est pas si simple. Il y a des pressions pour apporter des changements, et c’est assez logique, sur les versions intermédiaires Y, pour différentes raisons, et au vu du fonctionnement des « surcharges » possibles de quasiment tous les fichiers de SPIP, tu as vite fait de potentiellement casser quelque chose chez quelqu’un, même sans le vouloir, sans le savoir…

C’est à l’équipe en charge de SPIP, donc nous collectivement, de s’organiser pour arriver à ce résultat, et aussi du coup d’attendre des versions X pour casser l’existant (supprimer les fonctions dépréciées, CSS / JS dépréciés, etc), apporter des modifications plus fondamentales / structurelles.

Et je crois qu’on progresse… et qu’il faut continuer et s’améliorer encore sur cette voie.

Si on arrive à faciliter les releases (on a bien progressé sur les releases de maintenance), notamment les releases intermédiaires (Y+1), en s’assurant de rester semver au maximum, et même si ces releases ne contiennent que qq petites nouveautés (ça ne me choque pas), bien oui, tu peux dire pour les plugins vous êtes compats X.* plus facilement…

Mais c’est donc à nous de démontrer et réussir cela. Pour l’instant faire des releases Y+1 c’est un peu plus de travail, mais c’est pas infaisable.

2 « J'aime »

On a un peu le serpent qui se mord la queue sur les release en Y + 1 : comment on a pris pour postulat actuel que un Y + 1 ca casse, alors on n’ose plus trop faire des releases, car c’est reprendre plein de plugins.

En dehors de cela, il y a peut être d’autres complexité sur les Y + 1, mais je ne suis pas assez dans le processus de release pour percevoir.

Dans l’absolu, je serai favorable à une release Y+1 tous les ans / 18 mois, pour apporter petit à petit des nouveautés, en restant semver. Avec les nouveaux groupes, on peut imaginer d’étoffer un peu plus l’équipe de releasing.

1 « J'aime »

J’arrive comme un cheveu sur la soupe et je n’ai pas la prétention de vous dire quoi faire. Néanmoins, est ce que la réponse à la question ne pourrait pas être plus simple si le système de plugins SPIP n’était pas un peu plus testable de manière automatisée? Dans une CI sur la toute nouvelle forge?
À titre personnel et dans un autre registre, j’ai une instance yunohost chez moi et j’appécie leur système de packaging des applications: Testing your app | Yunohost Documentation
On voit tout de suite si on est en train d’installer une appli un peu foireuse ou un truc robuste.

Pour en revenir à Spip, d’il y avait des tests unitaires dans chaque plugin ça permettrait assez rapidement de savoir si:

  • on est en train de péter un truc en touchant le noyau
  • si ça concerne 1 plugin un peu abscons pas mis à jour depuis 3 ans ou les 15 plugins les plus utilisé de spip-contrib
  • déstresser potentiellement pas mal de monde (tant côté développement que côté webmestre) sur le potentiel de « dégats » de la nouvelle version SPIP (que ce soit une X ou une X.Y)

J’ai conscience que les tests unitaires c’est long et chiant, mais quand on en a on est bien contents.

Mes 2 cents

4 « J'aime »

Franchement je ne suis pas convaincu par une application stricte de semver ni même de son utilité. Je crains que ça nous confine in fine dans un certain immobilisme car nous ne faisons pas des releases tous les mois ou tous les trimestres.

J’ai quand même l’impression que semver appliqué strictement s’adresse plus aux développements rapides mais je peux me tromper. Après il faudrait faire une évaluation des pros et des cons pour spip spécifiquement.

Ce n’est pas si simple. Il y a des pressions pour apporter des changements, et c’est assez logique, sur les versions intermédiaires Y, pour différentes raisons

Pour ça je ne vois pas trop où est le soucis… c’est justement bien le principe même des Y d’ajouter des fonctionnalités ! Donc encore heureux qu’il y ait des ajouts sur les Y haha… C’est sur les Z qu’il ne devrait pas vraiment en avoir.

et au vu du fonctionnement des « surcharges » possibles de quasiment tous les fichiers de SPIP, tu as vite fait de potentiellement casser quelque chose chez quelqu’un, même sans le vouloir, sans le savoir…

Pour ce point, ça me parait anecdotique : si on parle de gens/de plugins qui ont surchargé vraiment des choses, alors bah oui à la marge ça peut casser parfois, mais ça fait justement partie de l’exception où là tel ou tel plugin ponctuellement aurait sa compat max en X.Y.

Mais la majorité des plugins ne fait qu’utiliser des fonctions d’API telles quelles, donc ya aucun soucis… si dans les Y du core on ne casse rien d’important.

C’est à l’équipe en charge de SPIP, donc nous collectivement, de s’organiser pour arriver à ce résultat, et aussi du coup d’attendre des versions X pour casser l’existant

Bé oui c’est le cœur de ma question hein :slight_smile: : est-ce que là maintenant (ou au moins pour dans quelques mois pour SPIP 5 puis 5.1) on est suffisamment ok là dessus pour que majoritairement les plugins aient un max en X ?

Alors non, pas forcément rapide. Enfin je sais pas ce que tu entends par rapide cela dit… mais par exemple Symfony sort 1 version majeure X.0 tous les 2 ans, et 1 version Y tous les 6 mois… en respectant semver.

C’est sûr que c’est pas forcément entièrement transposable pour Spip, avec une interface graphique qui peut évoluer, mais je ne vois pas trop ce qui restreindrait réellement de le faire.

nous ne faisons pas des releases tous les mois :

Alors déjà SI :stuck_out_tongue: on fait une release de maintenance tous les mois depuis quelques temps :slight_smile:

Mais oui, pour une version intermédiaire ou majeure, ce n’est pas si souvent ; cela dit, je suis persuadé qu’on pourrait, en améliorant la méthodologie de release (automatiser plus, tester plus et automatiquement surtout), on pourrait faire des versions Y plus souvent que 1 fois par an (et on a raté le coche cette année), en acceptant qu’il n’y ait pas forcément des choses révolutionnaires dans ces versions, mais des petites (ou plus grandes) améliorations. Ce qui permettrait de satisfaire et possiblement motiver plus de personnes, si tu sais que certains développement peuvent s’intégrer dans une version dans pas trop longtemps…

Je ne parlais pas d’ajouts, mais de changements justement (mais j’ai pas été clair, et je me suis peut être embrouillé moi-même, désolé !)

Mais oui c’est bien l’idée :

  • pas de nouveauté / changement sur Z (bugfix),
  • des nouveautés sur Y, mais pas de changements de comportements, d’api, etc si possible.
2 « J'aime »