Puisque l’on est à l’orée du nouvelle version SPIP, je voulais faire un petit (r)appel sur les plugins SPIP, leur vie, leur mort et leur renaissance…
Je pense que personne ne consulte la page de stats de Plugins SPIP mais elle nous donne quelques infos utiles sur les plugins et leur compatibilité SPIP.
Je trouve que cela montre qu’on perd toujours des plugins à chaque version.
Ce n’est peut-être pas grave mais en tout cas on ne sait pas pourquoi et c’est bien dommage.
Ca rejoint d’ailleurs la constatation que j’ai faite au cours de la réorganisation de Contrib (bientôt achevée pour Noel !!!), des plugins disparus sans laisser de trace ni d’explication.
C’est d’ailleurs pourquoi j’ai prévu dans le plugin Archive des objets un champ raison pour préciser pourquoi on archive un objet (mais c’est un autre sujet).
Donc à l’occasion de la 3.3 et de l’arrêt de certaines version obsolètes je pense qu’il sera utile d’utiliser ces listes pour vérifier si il ne faut pas faire renaitre certains plugins intéressants.
Et la cerise sur le gateau sera aussi d’assurer une cohérence avec Contrib et l’archivage des plugins.
Autre chose, je pense qu’on pourrait utiliser ces listes pour avancer sur le pass
(Séquence de touche qui tue et qui a envoyé le message trop vite, je le renvoie complet !)
Puisque l’on est à l’orée du nouvelle version SPIP, je voulais faire un petit (r)appel sur les plugins SPIP, leur vie, leur mort et leur renaissance…
Je pense que personne ne consulte la page de stats de Plugins SPIP mais elle nous donne quelques infos utiles sur les plugins et leur compatibilité SPIP.
Je trouve que cela montre qu’on perd toujours des plugins à chaque version.
Ce n’est peut-être pas grave mais en tout cas on ne sait pas pourquoi et c’est bien dommage.
Ca rejoint d’ailleurs la constatation que j’ai faite au cours de la réorganisation de Contrib (bientôt achevée pour Noel !!!), des plugins disparus sans laisser de trace ni d’explication.
C’est d’ailleurs pourquoi j’ai prévu dans le plugin Archive des objets un champ raison pour préciser pourquoi on archive un objet (mais c’est un autre sujet).
Donc à l’occasion de la 3.3 et de l’arrêt de certaines version obsolètes je pense qu’il sera utile d’utiliser ces listes pour vérifier si il ne faut pas faire renaitre certains plugins intéressants.
Et la cerise sur le gateau sera aussi d’assurer une cohérence avec Contrib et l’archivage des plugins.
Autre chose, je pense qu’on pourrait utiliser ces listes pour avancer sur le passage à Git : vérifier la structure en trunk de tous les plugins 3.2 et 3.1 par exemple, et les transférer TOUS sur Gitea plutôt que de le faire au petit bonheur la chance quand il nous tombe une dent…
Mon avis (et je le partage),
c’est que la plupart du temps ce n’est pas le changement de version SPIP qui pose le moindre soucis, mais simplement que le plugin a arrêté d’être maintenu parce qu’il a perdu son intérêt, que la lib sur laquelle il reposait n’est plus maintenue, que plus personne ne l’utilise, y compris son développeur initial…
Et du coup il reste figé dans son état de compatibilité dans lequel il était.
Je pourrais t’en citer une palanquée comme ça : openid (protocole mort), persona (techno mozilla abandonnée), spip_thelia (concernait la version Thelia 1 qui n’est plus maintenue), cloudzoom (librairie JS plus maintenue), video accessible (player video utilise plus disponible dans les même conditions de licence), shortcodes (personne ne l’a jamais utilisé visiblement, et même pas moi), ispip (lib js/techno obsolète), flattr…
Ensuite tu as aussi un grand nombre de plugin qui ont évolué en autre chose, mergé, intégré au core, et du coup ce sont des branches mortes : microblog, commandes_paypal, minidoc, ordoc, editer_liens_simples, forms, sphinx, cfg, jquery, feedburner, twidget…
Peut-être ça vaudrait le coup d’ajouter un statut « deprecated » (ou equivalent) dans le paquet.xml, qu’on puisse officiellement déclarer mort un plugin ?
Mon avis (et je le partage),
c’est que la plupart du temps ce n’est pas le changement de version SPIP qui pose le moindre soucis, mais simplement que le plugin a arrêté d’être maintenu parce qu’il a perdu son intérêt, que la lib sur laquelle il reposait n’est plus maintenue, que plus personne ne l’utilise, y compris son développeur initial…
Oui tout à fait, je pense que ma phrase était ambigue, je ne voulais pas dire que c’était le changement de SPIP qui induisait l’arrêt d’un plugin.
En fait, le changement de version est un révélateur au travers de la statistiques de ces pages : le plugin qui n’a pas franchi la 3.2 c’est qu’il a arrêté d’être maintenu comme tu le dis en 3.1 ou est devenu inutile en 3.2 car remplacé par SPIP ou un autre plugin.
Comme tu le dis il y a des tas d’exemples et je peux te dire que dans la doc de Contrib il y a en a aussi et qui ne sont pas étiquetés en obsolète ou deprecated.
Et du coup il reste figé dans son état de compatibilité dans lequel il était.
Je pourrais t’en citer une palanquée comme ça : openid (protocole mort), persona (techno mozilla abandonnée), spip_thelia (concernait la version Thelia 1 qui n’est plus maintenue), cloudzoom (librairie JS plus maintenue), video accessible (player video utilise plus disponible dans les même conditions de licence), shortcodes (personne ne l’a jamais utilisé visiblement, et même pas moi), ispip (lib js/techno obsolète), flattr…
Ensuite tu as aussi un grand nombre de plugin qui ont évolué en autre chose, mergé, intégré au core, et du coup ce sont des branches mortes : microblog, commandes_paypal, minidoc, ordoc, editer_liens_simples, forms, sphinx, cfg, jquery, feedburner, twidget…
Peut-être ça vaudrait le coup d’ajouter un statut « deprecated » (ou equivalent) dans le paquet.xml, qu’on puisse officiellement déclarer mort un plugin ?
Je pense qu’il faut y réfléchir oui.
Et c’est vraiment connexe à Contrib car on a aussi pleins de très vieux plugins qui ne sont pas identifiés en plugin car il ne sont plus zippés et pourtant ils pourraient encore être intéressants au moins dans l’idée. Et comme on ne sait pas pourquoi on les a abandonné ils pourrissent comme dans un désert de film apocalyptique.
Et je pense que la question aussi rejoins deux choses plus techiques :
pourquoi arrête-t-on de zipper un plugin et, aussi, pourquoi avoir ce lien entre l’existence du zip et le fait que le plugin soit obsolète ou pas
lors du passage à Git que faut-il transférer comme liste de plugins ? Tous ? ceux compatibles avec une version donnée ? autres ? Il faut noter que lors du passage à Git la problématique du zip doit être revu car on a plus besoin de l’archivelist, le zip étant disponible dans la forge et le lien est déterministe.
Je pense qu’il y a de vrais questions dans tout ça et que la refonte de Contrib et le passage à Git sont de bons vecteurs pour y réfléchir.
Dans les colonnes A et B on a la liste des plugins ayant bien un trunk (préfixes colonne A) et le chemin relatif dans la zone (colonne B). Il y en a 377 sans compter les nouveaux (ma liste date un peu).
A droite dans la colonne D on a la liste des plugins 3.2 mais qui ne sont pas en trunk. Je n’ai pas par contre le chemin sur la zone. Il y en a 244 sans compter les nouveaux
Je me dis qu’avec ces listes on devrait pouvoir automatiser le passage sous Git des plugins en trunk rapidement en comparant avec l’état actuel.
Il faudrait utiliser l’API pour avoir la liste de l’organisation Plugins par exemple.
Et pour l’autre liste sans trunk on peut l’utiliser pour commencer à passer en trunk à moins qu’il y ait une autre façon de faire.