Re: Gitea et le débardeur

Le 05/01/2021 à 17:13, Eric Lupinacci a écrit :
> 1) Le problème ne concerne pas les tags ni la génération systématique des zips par le débardeur. On pourrait même étendre à l'ensemble des tags si on voulait... Maintenant, ne pourrait-on pas éviter de regénérer les zips existant sur Gitea ?

C'est pas déjà le cas, genre si le débardeur voit que ça existe sur gitea, il le récupère tel quel ?

> 2) Il faut adapter les affichages sur Plugins SPIP (et bientôt Contrib) pour mettre en avant les dernières versions de chaque branche et en second rideau les autres versions (ergo à définir).

+1

> 3) Un changelog serait utile à la fois dans les affichages Plugins SPIP et dans SVP afin de décider de la mise à jour en connaissance de cause.
> 4) Le plus simple et portable serait de créer un fichier CHANGELOG.txt ou .md à la racine des plugins qui pourrait être utilisé par Plugins SPIP ou SVP sous un forme à définir.
> 5) le format du changelog pourrait s'inspirer de : https://keepachangelog.com/fr/1.0.0/
> 6) l'existence du changelog est facultative.

+1, c'est un autre sujet qui là nécessite des évolutions à l'infrastructure (pas juste l'affichage final), mais clairement oui : il y a d'ailleurs un ticket déjà dessus depuis 5 ans…
https://core.spip.net/issues/3509
 
> Ca peut faire une roadmap sympa il me semble non ?
Sur les tickets, il y a des choses qu'on a liées au 3509, notamment

- https://core.spip.net/issues/4256 qui parle de distinguer (donc étiqueter en amont, donc infrastructure aussi) spécifiquement les màj contenant de la sécurité : ce n'est pas pareil que Z qui change (ça peut être sécu ou juste petit bug, on sait pas), et ce n'est pas pareil qu'un changelog complet, qui est le détail humain, mais qui ne permet pas de le savoir informatiquement, et donc de le mettre en avant (que ce soit sur les sites de la galaxie ou dans les SPIP des gens)

- https://core.spip.net/issues/3017 dont la conséquence est que SVP devrait être amélioré pour connaitre plus qu'une unique mise à jour existante : en effet à un instant T, un plugin peut avoir une version majeure sortie X+N *et* une version Y+N ou même juste Z+N, et l'utilisateur ne veut PAS forcément changer de X, mais bien changer que Y voire même ne changer que Z pour être sûr de ne rien casser et avoir juste les corrections. Au niveau ergonomique, le travail est en gros fini, mais par contre, la conception de SVP ne le permet pas, donc pas possible de générer plusieurs boutons de mises à jour différentes à la fois. (Exemple de Sézi dans la maquette, qui a 4 mises à jour possible à la fois)

Ce dernier point est le plus compliqué il me semble, car SVP c'est compliqué et qu'il y a eu un gros angle mort de conception sur ce point on dirait. Cependant j'ai l'impression que pour les utilisateurs finaux (qui ne suivent pas le code), c'est encore bien plus important qu'avoir le changelog complet : les gens devraient absolument pouvoir faire des mises à jour mineures, sans qu'on leur montre uniquement la majeure, et illes sont capables de choisir l'option la moins dangereuse pour elleux même sans changelog complet avec les phrases claires et simples (on comprend la différence entre "màj corrective/fonctionnelle/majeure" et donc la dangerosité ou pas à changer sans tout péter).

Mais faisons déjà les choses "simples", sur lesquelles on a la main plus vite.

-- 
RastaPopoulos

_______________________________________________
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip