Je viens de remettre en état Plugins SPIP suite à son passage en spip 4.
Retour des commites pour les plugins développés sur Gitea et retour des pages qui avaient une sale gueule depuis quelques jours.
Et cerise sur le gâteau, les catégories sont bien les nouvelles initialisées il y a déjà pas mal de mois mais uniquement utilisées sur Contrib. Plugins SPIP et Contrib sont donc synchronisés sur les catégories.
Pour conserver le fonctionnement connu de Plugins SPIP on utilise uniquement les 11 catégories « racine » sachant que maintenant les nouvelles catégories sont à deux niveaux (activite/association par exemple).
Il reste encore quelques petits ajustements à faire:
traiter les paquets qui n’ont pas de branche spip compatible et qui sont identifiés comme déprécié;
mettre en exergue plus clairement le fait qu’un paquet soit déprécié
afficher la catégorie exacte du plugin en plus de la catégorie racine
A noter que les paquets de compatibilité [3.3.0-dev;3.3.*] ou [4.0.0-alpha;4.0.*] ne permettent pas d’identifier les branches compatibles car certaines bornes ne sont pas reconnues.
Il est préférable de ne plus utiliser 3.3 et de préférer l’intervalle ]3.2.999;4.0.*] pour une version sip 4 uniquement.
C’est super @eric_tonton …
mais… pourrais tu m’expliquer pour quelle raison xray XRay - Plugins SPIP et cachelab cacheLab - Plugins SPIP sont ils présentés comme n’étant compatibles avec aucune version de spip ? Du coup il n’apparaissent pas dans les recherches standards.
En fait DEV aussi (Développement - Plugins SPIP) du coup d’autres sûrement ? ya un pb.
Exactement pour la raison que j’ai expliquée plus haut. Les paquets sans branche spip sont ceux dont la borne max est 3.3.* alors que la branche 3.3 n’existe pas. Dans ce cas le traitement retourne une erreur et donc un intervalle vide.
Etant donnés que ces tags existent, il va falloir soit identifier la 3.3 comme connue de spip, soit cacher ces paquets ce que je préfèrerais.
Cela me fait dire que créer des tags sur une version spip non officielle est une mauvaise pratique étant donné que nous disposons d’un mécanisme pour faire marcher des plugins en foçant la compatibilité.
Première correction de la journée : j’ai intégrée la branche 4.0.0-alpha dans SVP ce qui a pour effet de récupérer la branche 4.0 pour les plugins qui l’utilisent. On retrouve donc pour ces plugins un affichage « non déprécié ». J’ai regénéré l’ensemble des dépôts.
Par exemple, XRay retrouve un paquet 4.0 clairement identifié : XRay - Plugins SPIP.
Bon, une proposition pour rétablir une vision plus correcte des paquets ayant intégrés trop tôt la 3.3 : on introduit dans SPIP cette branche avec borne min et max à 3.3.0-dev et sous Plugins SPIP on la considère non maintenue, ce qui est le cas.
De cette façon, les paquets retrouveront une liste de branches et seront quand même marqués dépréciés ce qui est vrai.
Faiseur d’ange ! Même si elle ne verra jamais le jour, cette 3.3 a existé pour de nombreux plugins et sites, donc c’est pas abérrant de lui reconnaître ce statut… (Ou sinon remplacer tous les 3.3 par des 4.0 dans les paquets.xml ?)
Mais il semble y avoir d’autres problèmes :
Pour DEV ça semble aussi un autre pb. Quand on est sur sa page « pour spip 4.0 », le tag « SPIP 4.0 » est barré : Développement - Plugins SPIP, bien que le tag apparaisse dans le détail de la version 1.0.0. De plus, la présentation de cette version ne se distingue pas des autres versions pour SPIP 3.2 ou 3.1 par exemple. Seule la version 3.3 est grisée. C’est pareil pour la pge pour SPIP 3.2
Rq : Il est pénible ici d’avoir des numéros de version différent du numéro du tag.
Les recherches de « Développement » ou de « 'Cachelab » ne fournissent pas de-le résultat attendu.
Pour cachelab, son tag 1.2 (celui qui a 4.0.* comme borne max) semble ne pas parvenir à plugins.spip.
Ton tag v1.2.0 a comme version 1.1.4 dans le paquet.xml : donc il est bien affiché ! Je pense qu’il faudrait le virer et le recréer après avoir changé la version du paquet.
Les recherches de « Développement » ou de « 'Cachelab » ne fournissent pas de-le résultat attendu.
Je pense que c’était le cache. Après vidage j’ai un résultat correct il me semble.
Pour DEV ça semble aussi un autre pb. Quand on est sur sa page « pour spip 4.0 », le tag « SPIP 4.0 » est barré
Oui, faut que je vois pourquoi.
Rq : Il est pénible ici d’avoir des numéros de version différent du numéro du tag.
Pour DEV j’ai trouvé : c’est du au paquet le plus ancien qui à pour intervalle de compat [2.3.0-dev;]. Donc joie et félicité avec cette branche 2.3 dont on ne sait d’où elle sort surtout que la 2.2 n’a jamais vu le jour non plus. La fusion des intervalles de tous les paquets donnent [2.3.0-dev;4.0.0] pour le plugin et donc la borne n’existant pas la liste des branches du plugins est vide !
Donc là c’est bien emmerdant parce qu’il n’est pas question de rajouter cette branche qui n’a jamais existé du tout. Le plus simple serait de virer ce tag qui est un non sens à mon avis car en plus il n’est pas borné.
Pas simple tout ça…
OK. J’avais abondamment ?var_mode=recalcul pourtant.
Pour les n° de versions de « dev » : le n° de version du plugin est différent du n° indiqué par le tag ET tous 2 sont différents de la version unique de SPIP pour laquelle chacun est compatible.
C’est corrigé avec la nouvelle version de SVP.
On calcule différemment les branches d’un plugin ce qui fait que même si un paquet renvoie une erreur cela n’a pas d’impact sur tout le plugin.
C’est donc beaucoup mieux.
