Bornes max des plugins compat 4.2

Dev
#1

Hello,

Lors de la publication du dernier CR Maintenance, nous avons posé une question qui se voulait ouverte mais qui est restée à ce jour sans réponse, ni réaction.

Je vais donc procéder à un traitement en masse pour mettre à jour la borne max de quelques plugins, sauf si opposition franche et massive.

Suite à la campagne d’archivage, nous sommes dans la situation suivante :

  • 1011 projets (dépôts git publics, non-archivés, dans les groupes spip-contrrib-extensions, spip-contrib-graphismes, spip-contrib-outils, spip-contrib-squelettes, spip-contrib-themes et spip-galaxie.
  • dont 974 plugins maintenus
  • parmis lesquels on peut compter 572 plugins compatibles avec SPIP4.2 ou plus, avec des bornes max rédigées comme suiit :
notation occurences
;4.*.*] 20
;4.*] 3
;4.2.*] 539
;4.3.*] 3
;4.99.*] 1
;5.0.*] 1
;[ 4
;] 1

Pour les plugins-dist, nous avons opté pour la notation 4.*.

Je vais donc mettre à jour les fichiers paquet.xml des 539 plugins compatibles 4.2.* en mettant 4.*

Première option

  • Je crée une branche dans laquelle je modifie paquet.xml sur la borne max, fait une PRs, et je m’arrête là.
  • Libre aux mainteneureuses d’approuver/merger/faire « el famoso » up de z et plus si affinité.

Seconde option

  • Je modifie paquet.xml, fait « le truc » du z+1 directement dans la branche par défaut, et je m’arrête là. (EDIT: mais je peux très facilement poussé jusqu’au tag…)

Il n’y aura pas de comptes d’apothicaire, c’est soit l’un soit l’autre sur la masse de plugins éligibles au moment de l’opération.

Voilà

À vous lire,

#2

A t’on une idée des quelques en question ?

Pour la seconde option je ne pense pas non.
Il faut effectivement up de z, et faire un tag pour diffusion du zip.
Donc le faire après validation explicite d’une PR.

Est ce que tu pourrais d’ailleurs ajouter quelque chose comme ça automatiquement dans le message de la PR :
« Après la validation de la PR, mettre à jour le paquet.xml (z+1) et générer un nouveau tag »

#3

+1 pour la première option, à charge à chacune de réagir sur sa plugin si ça ne convient pas.

#4

Est-ce que l’une des options est plus contraignante pour toi en terme de temps et d’énergie ?

#5

Les 2 options sont prêtes. Exemple de la première ici : Compatibilité 4.* (!6) · Requêtes de fusion · spip-contrib-extensions / calendrier_mini · GitLab sans la moindre réaction depuis un mois environ …

#6

abstention pour ma part, je n’arrive toujours pas à trancher.

#7

Première option éventuellement, sous réserve du non-reformatage du paquet.xml

Cf Compatibilité 4.* (!6) · Requêtes de fusion · spip-contrib-extensions / calendrier_mini · GitLab

#8

Je peux t’aider @maieul,

Quelques plugins (une grosse vingtaine) ont été mis à jour à la mimine, pour la plupart je pense, directement dans leur branche par défaut pendant qu’une PR est restée lettre morte un certain temps…

#9

Moi je préfèrerai que ça reste une PR, validée manuellement ensuite, car je garde une mauvaise expérience d’un changement de version massif qui avait été fait à l’époque de la 1.9 où tout avait été passé en « compatible 1.9.2 » arbitrairement, mais comme en vrai cela ne correspondait à aucune réalitée testée, cela devient du coup une « non-information » (puisque idem pour tout le monde) et on perd même l’info qu’on avait « avant » qui n’était pas rien, même si c’est plus ou moins fiable selon les plugins

#10

Pas de soucis, c’était mon idée première aussi. L’expérience sur calendrierminim’a un peu refroidi, mais bon…

ça fera 500+ PRs, mais ça me va. (juste que ça demande de les traiter quoi …)

Par contre, vu le temps qu’une validation/fusion peut prendre, pour éviter le risque de conflit au niveau de l’attribut version, au cas où il y aurait d’autre commits dans la branche d’origine dans l’entrefaite, je pense qu’il est plus prudent de ne pas modifier la version dans le fichier.

#11

+1

#12

Oui tu as pas choisi le meilleur cheval, car comme je suis pas super chaud de ce « 4.* » j’ai me suis pas spécialement précipité pour valider cette PR :stuck_out_tongue:

#13

:smiley:

c’était vraiment au pif. Pas de bol :smiley:

#14

Je comprends.

Nous avons particulièrement fait attention à ne pas introduire de BC Break entre la 4.2 et la 4.3, mais, effectivement, nous ne sommes ps à l’abri d’un loupé … mais comment s’en prémunir aujourd’hui ? (de manière automatique, j’entends)

#15

Oui je suis pas trop inquiet pour la 4.3 de ce que j’ai vu, mais 4.* c’est un engagement pour la vie pour toutes les 4.x qui sortiront et bien malin qui peut dire qu’on arrivera toujours à tenir la barque (notre passé ne plaide pas pour nous…)

Mais passer automatiquement tous les plugins actuellement compat 4.2 en compat 4.3, par exemple, ne me gênerait pas, car là on sait de quoi on parle

#16

Bon comme d’habitude j’ai encore tout loupé cette semaine :wink:

Je ne suis pas hyper fan de 4.*, je trouve que ça casse une stratégie qui fonctionne depuis des années, enfin de mon point de vue. Si la décision est prise, moi je ne suis pas fan d’une PR car je vais devoir me taper les plugins un par un.

Et comme @cerdic j’aurais préféré un 4.3.*

#17

La stratégie ne « fonctionne pas » depuis des années : ça fait justement des années qu’à chaque nouvelle version SPIP (y compris donc les Y+1 qui ne sont PAS censés casser des choses une fois qu’on suit mieux semver, mais ok ce n’était pas le cas avant), et on se retrouve pendant des mois et des mois avec des plugins pas encore activables. Les gros devs et admins sys s’en sortent, mais les gens non tech qui font leurs mises à jour se retrouvent le bec dans l’eau pendant des mois car même si SPIP peut être mis à jour, pas les plugins, et donc les gens… ne font pas la mise à jour sur le moment… puis ensuite oublient… et donc sont en retard dans les mises à jour.

La stratégie du futur, càd en s’améliorant continuellement (on part de ce principe), c’est de suivre semver de plus en plus correctement, et donc obligatoirement ça veut dire que les Y+1 ne casseront plus rien ou presque et donc que les plugins sont forcément ok pour la version suivante (sauf très rares exceptions, mais donc la norme c’est que ce soit compatible par défaut).

#18

C’est sur qu’à partir du moment où on part d’un postulat inverse on ne risque pas d’arriver à la même conclusion. Ce que tu dis ne pas fonctionner moi je considère que c’est justement un fonctionnement correct et que ce n’est pas la stratégie qui est mauvaise c’est le fait de ne pas s’en préoccuper.

Donc on court devant et on regarde si ça fonctionne après en se rassurant par une pseudo norme dont 90% des gens se foutent. Mais j’ai surement tord d’ailleurs j’arrive à la fin du fil donc c’est une preuve.

#19

On ne court pas devant, toi tu parles du point de vue des devs de plugins comme si ce n’était pas dépend du contenu concret de chaque release de SPIP.

Moi ce que j’explique, c’est que ça fait quelques années que du côté du core, il y a une volonté d’augmenter chaque fois le sérieux du suivi de semver, et c’est mesurable que ça marche et que chaque dernière release était plus carré de ce point de vue. Et donc on peut raisonnablement partir du principe que ça va continuer de s’améliorer sur ce point, et donc qu’au final, chaque nouvelle release Y+1 ne cassera réellement jamais de choses importantes.

C’est toujours du core qu’on part avant de réfléchir aux plugins.

Et donc dès lors qu’on en est vraiment à ce point de « propreté » (on peut toujours dire qu’on peut mieux faire, mais on a déjà beaucoup avancé !) et bien il est totalement raisonnable et logique de dire que les plugins sont ok pour « X.* » puisque forcément les Y+1 ne vont rien casser, ou rien de très grave.

#20

Oui enfin on testera encore moins les plugins.
A priori c’est pas grave…