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.
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 »
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…
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
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.
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)
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
Bon comme d’habitude j’ai encore tout loupé cette semaine
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.
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).
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.
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.
