Bornes max des plugins compat 4.2

Dev
#21

Bé oui oui tu as bien raison :slight_smile: , mais c’est justement le but recherché : ne pas avoir à tester quand ya pas besoin puisque ça n’a en gros aucun sens, à partir du moment où le core est assez propre pour que chaque release Y+1 ne casse rien et qu’on le sait d’avance.

Il n’y a à tester que quand c’est utile : quand on change X+1 et qu’on sait qu’il y a des gros changements cassants.

Et j’ajoute que c’est le cas dans plein d’autres CMS, en premier lieu Drupal : ya plein de plugins qui sont marqués comme étant compat 8.* ou 9.*. Ce qui est cool et pratique et permet de mettre à jour dès que le noyau change seulement de Y, sans attendre des mois.

2 « J'aime »
#22

Bon,

moi ce que je percois c’est que

  1. Il y a un consens pour que ce soit les responsables de plugins qui décident en conscience de changer la borne
  2. Certain·es sont plus prudent·es, d’autres plus confiant·es ; les premier·es veulent 4.3.*, les autres 4.*
  3. Quoi qu’il en soit, si on passe par PR + validation manuel et release manuel, il y a un travail à faire manuellement et un choix à faire

J’en arrive à la conclusion qu’à ce compte là, autant laisser les responsables faire elleux meme le travail plutot qu’un script qui ne ferait que la moitié.

Et cela permet aux gens de faire leur choix entre 4.* et 4.3 selon leur propre approche.

Pour ma part, je ferais sur les plugins que je maintiens des 4.* (parce que j’ai confiance dans le semver) et je proposerai pour ceux que j’utilise des 4.3 (parce que je vais faire les tests).

3 « J'aime »
#23

Alors franchement s’il est possible de passer tous les plugins compat 4.2 en compat 4.3 avec un script et de générer les tags qui vont bien c’est quand même une solution toute en sérénité :

  • A la mise à jour de 4.2 en 4.3 les utilisateurs ont direct leurs plugins OK (sans être obligé de trafiquer mes_options.php)
  • On ne prend pas de risque sur les évolutions futures, à la 4.4 il doit être possible de lancer le même script 4.3 → 4.4 si c’est bien toujours compatible

D’autant que comme SPIP suit les versions php il y aura probablement des ajustements à faire tout de même sur les plugins pour que ça passe avec les nouvelles versions php.

Donc je rejoins Cédric et Eric, la proposition de taguer de 4.2 à 4.3 me semble simple et efficace

#24

Piste : Si une mesure par défaut est décidée, chacun⋅e pas d’accord peut s’exprimer, et ensuite la mesure par défaut est appliquée SAUF pour les plugins dont un⋅e des auteur⋅ices déclaré⋅es dans le XML s’est manifesté comme pas d’accord.
Et s’il faut simplifier le boulot de mise au point du script, ce peut être les auteur⋅ices pas d’accord qui listent les plugins qu’ils veulent exempter.

#25

Faut peut-être pas pousser non plus. @JamesRezo il est pas là pour vérifier qui a envie de quoi déjà qu’il propose un script.
On discute, on prend une décision et basta, l’important c’est de pouvoir en discuter pas que ça plaise à tous in fine, ce qui est illusoire.

1 « J'aime »
#26

Après relecture du fil et réflexion, je me range aux avis de @cerdic et @eric_tonton qui me paraissent raisonnables.

Le script pourrait :

  • modifier le paquet.xml (z+1 directement dans la branche par défaut) mais juste pour les plugins actuellement 4.2.*
  • pousser le tag

Et à renouveler, lors de la sortie de la 4.4 et autres z+1

Par contre, je reviens là dessus : ce serait bien de ne pas casser le formatage des paquet.xml, pour les garder humainement lisibles :

#27

Si on met juste tout en 4.3 en masse… puis qu’on renouvelle pour 4.4, etc (qui sont des Y+1 plutôt)… bah c’est littéralement comme si on avait mis 4.* dès le départ non ? :stuck_out_tongue:

Le fait de mettre 4.* dès maintenant, permet aussi inversement de dire : soit attentif gentille équipe maintenance, tout comme la 4.3 est déjà bien fichue niveau semver, la 4.4 devra continuer de l’être aussi, et tutti quanti. Ce qui pousse d’autant plus à s’améliorer sur ce point et à ne rien introduire de cassant dans toutes les Y+1. Ce qui tombe bien puisque c’est ce vers quoi on veut tendre au mieux.

#28

Y a quand même un truc qui me chiffonne à ce propos que je ne soutiens pas d’ailleurs.
On dit qu’un coté qu’on a quand même du mal à sortir régulièrement des versions.
De l’autre coté on se met en position de ne pas beaucoup faire évoluer les versions x.y à chaque évolution de y.

Donc je me dis qu’il va falloir attendre les versions x pour des changements : vous ne pensez pas que ça confine quand même beaucoup à l’immobilisme ?
Alors je vois venir la remarque éternelle de « faire comme les autres » (comme Panurge ?) et des standards qu’on adore (sauf quand on les paye tous les jours) mais est-ce que les organisations qui nous expliquent que c’est génial n’ont-elles pas les moyens elles d’avancer bien plus vite que nous ?

#29

Donc je me dis qu’il va falloir attendre les versions x pour des changements : vous ne pensez pas que ça confine quand même beaucoup à l’immobilisme ?

ce n’est pas ce qui est dit. Ce qu’il faut c’est attendre les versions x pour des changements QUI CASSENT des fonctionnements. L’ajout de nouveauté peut et doit se faire en version y. C’est ce qui permet précisement de sortir plus souvent des versions y : parce que ce qu’on n’y met NE CASSE PAS, alors on n’a moins de processus manuel à faire pour vérifier les compat de plugins, et ont garde son énergie sur autre chose.

1 « J'aime »
#30

Je ne m’interroge pas sur ce qu’on dit ou imagine mais je m’interroge sur ce qui se passera réellement.
On verra donc.

#31

Je précise que mes scripts n’ont pas du tout vocation à être maintenus et exploités dans la durée. Ni publier…
C’était du one-shot, l’idée étant d’éclaircir la situation et de redonner la main aux contributeurices le plus vite possible …

  • Il va y avoir des releases de SPIP au plus tard vendredi prochain, dont une 4.3-qqc. J’espère que ce sera 4.3.0-beta. Et j’espère qu’elle sera accompagnée d’un « code freeze ».
  • Dans moins de 2 mois, la 4.3.0 « stable » devrait sortir et
  • dans 8 mois environ, c’est la 4.4 LTS qui arrivera.
  • Bien que certain·e·s d’entre nous aient envie et confiance dans ce modèle, j’entends le manque de sérénité des autres.
  • Pour autant, on sait que l’adoption d’une nouvelle version mineure dépend avant tout de la disponibilité de plugins compatibles.

Et je maintiens.

Pour autant, ce serait une bonne idée d’ajouter un critère d’éligibilité supplémentaire, les groupes GitLab.

À la relecture de cet échange, il semble admis que, bien que dans un seul et même groupe (spip-contrib-extensions) principalement, chaque plugin à ses mainteneureuses spécifiques, ses règles, ses méthodes, son rythme.

Techniquement, ça veut dire que « des personnes » s’organisent différemment autour d’un ou plusieurs plugins, mais au même endroit (dans un groupe).

  • Je pense que ces personnes y gagneraient à maintenir leurs plugins dans des groupes indépendants les uns des autres, en exposant leurs règles de contributions, notamment en matière de compatibilité SPIP, mais pas que.
  • Les utilisateurs de ces plugins y verraient aussi plus clair.
  • Les opérations de masses tels que l’archivage ou les mises à jours de compatibilité SPIP (et bien d’autres) seraient plus aisées aussi.

Concernant la mise à jour en masse des fichiers paquet.xml des 530 et queqlues plugins compatibles 4.2.*, je vous laisse poursuivre la réflexion, trouver un consensus entre vous, mais en l’état, j’aurais plutôt tendance à me ranger du coté de @maieul : « autant laisser les responsables faire elleux même le travail » …

#32

C’est bien le sujet de la discute quand même

#33

Un poil hors-sujet, mais pas tant que ça, quelques statistiques d’usage de git.spip.net :

Git user report

Git users       : 597
  Git bots/test :  10
  Humans        : 587

  Imported      : 557
  Created since :  40

                  Total Cr.  Imp.
Active users    : 119   20   99
  Since 4 months: 119   20   99 (2024-02-02)
  Since 3 months:  95   20   75 (2024-03-02)
  Since 2 months:  77   17   60 (2024-04-02)
  Since 1 month :  61   11   50 (2024-05-02)
  Since 1 week  :  40    3   37 (2024-05-26)

Rappels

  • pour faire un git clone https://git.spip.net/xxx/xxx.git, pas besoin d’avoir un compte GitLab.
  • Pas besoin de git pour installer et mettre à jour un SPIP ou un plugin.
  • Ces chiffres ne parlent donc que de personnes qui participent « activement », qui contribuent, à une ou plusieurs choses autour de SPIP, seules ou à plusieurs, peu importe leur degré d’implication, sur la plate-forme communautaire.

Quelques explications à propos des dates :

  • Les premiers tests de migratons gitea->gitlab ont commencé début février 2024 (date de création d’utilisateurs importés depuis gitea)
  • Annonce le 12 février et ouverture « officielle » le 2 mars
  • Création des « équipes » le 1er avril
  • Proposition assez concrète d’une 4.3 pour cet été fin avril/début mai
  • Nous sommes le 2 juin :slight_smile:

Quelques explications à propos des termes :

  • « Git bots/test » sont des comptes GitLab que j’ai peu identifier comme tels, à savoir des « bots » ou des comptes qui peuvent servir à des tests (comme par exemple salvatore pour la mise à jour des fichiers de langue ou « LambdaJames » pour que je puisse faire des captures d’écran de la plate-forme sans privilèges paraticuliers)
  • « Active users » correspond au nombre d’utilisateurices humain·e·s s’étant authentifiés au moins une fois depuis une date donnée et ont éventuellement poussé un commit, créé une issue, commenté …
  • « Cr. » veut dire « créer depuis l’installation de la plate-forme à l’initiative de nouvelles personnes »
  • « Imp. » veut dire « importés lors de l’installation de la plate-forme » autrement dit, des comptes utilisateurices historiques

Ça ne dit évidement rien de spécial, mais ça donne une idée du nombre de personnes dont « on » parle en tant que « devs », « mainteneureuses », « contributeurices ».

#34

Ouais, sauf que je ne vais pas scripter chaque cas particulier. Ça n’aurait ni sens, ni efficacité :wink:

#35

C’est un point sensible que tu soulève là. J’ai mes raisons de penser que cela peut être pertintent, mais cela mériterait un sujet à part.

1 « J'aime »
#36

J’y compte bien :wink:

#37

L’été dernier, j’ai contribué à déclarer compatibles SPIP 4.2 un grand nombre de plugins sans responsable visible.
Je ne suis pas le seul à avoir fait ça. Merci aux autres :wink:

Ça me semble donc un vœu pieu que d’espérer en ce sens.

#38

Je pense à un cas d’usage qui revient à chaque release mineure/majeure. À ce jour, la 4.3 est en beta et si on souhaite basculer un site de la communauté en 4.3 beta afin de participer aux tests de SPIP et de compatibilité des plugins on doit jouer avec le define _DEV_VERSION_SPIP_COMPAT (pour rappel, on sait par expérience que ce define génère des comportements parfois « étranges »). Dans ce cas, si un plugin comporte un bug, on signale celui-ci dans un ticket afin qu’il soit corrigé.

Si on appliquait 4.* aux plugins, cela permettrait de se passer de l’usage de ce define, pour les personnes qui souhaitent participer à la phase de beta test.

Reste que si un plugin marqué 4.* n’est pas utilisé par les gens lors de la beta test, il risque de générer des effets de bord chez les users une fois la 4.3 passée en stable, mais j’ai espoir que la communauté s’engage plus dans la beta test et amha ça ne changerait pas grand chose pour les users qui de toute façon fourbent pour tester un plugin incompatible avec le define ou en éditant directement le paquet.xml.

1 « J'aime »
#39

Il y a aussi un autre cas qui n’a pas été évoqué dans ce fil : la compatibilité PHP.

En effet, chaque nouvelle version y de la branche 4 est compatible avec une version plus récente de PHP.
Mais ça ne veut pas dire que les plugins le seront.

#40

Ça n’est pas le cas pour la 4.3 et la 4.2 qui ont les mêmes plages de compat niveau PHP.