Faudrait aller au delà des apparences et des impressions à mon avis. Et ne pas se mettre la pression inutilement si les plugins sont peu ou pas ou plus utilisés …
Il y a quelques mois, c’était 1 constante qui posait problème, entre 4.1 et 4.2, pour certains plugins qui l’exploitaient. En tout cas, j’en étais resté, de ce que j’ai pu lire en tout cas, à quelques cas de plugins, à la marge.
Maintenant c’est « des constantes », c’est très flou… S’il y a plein de cas d’incompatibilité, comment expliquer qu’il y a 2,5 fois plus de SPIP4.2 vérifiés que de 4.1 ?
Ces tableaux, je les mets en ligne pour que ça avance : pour que les plugins trouvent des mainteneureuses, éventuellement les re-dispatcher dans des nouveaux groupes git, ou pour les archiver en masse.
J’ai moi même rencontré plusieurs incompatibilités en faisant des mises à jour SPIP 4.2 → 4.2
Je ne les ai pas notées à chaque fois.
Alors c’est à la marge oui, pour des utilisations parfois limite, mais ça existe.
J’ai vu que tu en avais déjà passé plusieurs en compat 4.*
periodes
reservations_credits
reservations_bank
prix_objets_periodes
Ceux de rainer spécifiquement ? Je serai pour les revert.
Pour les compat ->4.1.*, il vaut mieux laisser les mainteneurs décider au cas par cas, j’y vois des gens qu’on connaît sur les derniers commits : @rastapopoulos@cerdic@maieul@erational@pierretux
[EDIT]
Pour les incompatibilités 4.1 → 4.2, le typage des arguments, par exemple, m’avait provoqué quelques erreurs fatales dans les squelettes
Autre exemple : dans un formulaire CVT, si _charger() ou _verifier() sont déclarées sans rien renvoyer, le formulaire n’est pas traité.
Exemple :
function formulaires_machin_verifier_dist(){}
et en 4.2, le formulaire s’arrête là, il ne fait rien.
Je pense qu’il est temps d’archiver les 12 qui ne sont pas ou plus utilisés sur les sites vérifiés et qui n’ont pas reçu de commits depuis plus de 18 mois …
Non pas svpbase comme je l’ai déjà dit car c’est le plugin qui extrait de SVP le référentiel des plugins (tables plugins et paquets) et qu’il faudra bien un jour mettre en place.
Le XML de « Chapitre » n’indique aucune doc, mais un commentaire indique que ce plugin sert à <!-- Ajouter des chapitres à n’importe quel contenu. -->
C’est intéressant, mais ça reste mystérieux.
Quelqu’un peut développer ?
Les juilletistes étant peut être dans l’impossibilité de suivre ce fil, il me semble préférable d’attendre la rentrée et relancer une consultation à ce moment avant d’envisager archiver des plugins.
il suffit d’un commit pour qu’un plugin sorte de la liste
L’objectif, c’est de faire le tri, de savoir où on en est, en terme d’activité, de développement collaboratif, de maintenance … de créer des groupes git si besoin(*), d’archiver des plugins abandonnés avec le plus de critères objectifs possible.
Je ne vois pas de raison à ça. Les durées sans activités (qui peuvent s’exprimer en années) de pas mal de plugins ne me donne pas espoir qu’on aura plus d’infos et de monde pour tailler le bout de gras dans 1mois qu’aujourd’hui. Le nombre de sites où d’autres sont utilisés idem (**)
D’un manière générale, repousser à plus tard, c’est repousser à jamais (voir Les jalons(milestones) de spip/spip)
(*) la plate-forme git permet de mieux organiser les choses en créant des groupes, avec des droits différents pour des utilisateurices identifiées comme mainteneureuses, développeureuses, rapporteurices, … la collection de plugins que ce groupe représente permet de mettre en place des règles de dév, des bonnes pratiques en fonction de ce que les membres décident. Ex: spip-contrib-extensions contient encore un millier (947) de projets, dont 740 actifs, et 529 membres considérés à peu près tous comme mainteneureuses… Or, on voit bien que c’est un groupe dans lequel chaque projet git est traité au cas par cas, parfois par une seule personne (donc, pas très collaboratif), qui applique ses propres règles… On peut faire mieux
(**) et ça vaut pour toutes les listes que j’ai mises en ligne ces derniers jours.
Je suis en pause jusqu’à la rentrée, et peut-être d’autres personnes sont dans mon cas. Si ces plugins qui tournent en 4.1 n’intéressent personne et que pour avancer vous jugez qu’il faut les archiver autant les détruire directement ainsi que leur doc rédigée sur contrib. Je n’ai apparemment pas les mêmes priorités mais je ne veux pas retarder vos avancées. ++
Faisant effectivement parti des juilletistes de retour de la plage de Pornic avec un gros coup de soleil, je ne pourrai regarder pour chapitres que la semaine prochaine au mieux.
