Avec Cédric nous avons testé hier et aujourd’hui un nouvel outil destiné à remplacer smart-paquets et surtout à faciliter la transition douce vers les zips de git (moi j’ai juste testé hein).
Cet outil est nommé débardeur, je vous laisse consulter wikipedia pour l’explication.
L’intérêt est que le débardeur est facile d’installation et de manipulation et permet de reconstituer les zips, les logos et les archives.xml à l’identique de smart-paquets.
Il est même capable d’agréger dans un même dépôt SVP des zips Zone et des zips Gitea.
De fait, il est possible de basculer petit à petit (mais pas trop quand même) des zips SP (qui consomment de la charge serveur) vers les zips Gitea qui existent une fois pour toute.
Le débardeur se base sur les tags uniquement !
Donc pas de tag Git, pas de débardeur.
Pas de débardeur… pas de débardeur.
Pour basculer les zips d’un plugins zone vers gitea, il faut que le plugin soit transféré sur Gitea (c’est aujourd’hui le cas de 90% des plugins compatibles SPIP 3.0 à 3.2) et qu’il existe des tags correspondants aux zips à fournir. On peut alors supprimer les lignes correspondantes du archivelist, le débardeur lit tous les repos des organisations Gitea (et même plus si besoin, le détail est dans le readme).
Simple et de bon goût.
Néanmoins, concernant les tags nous avons du limiter les tags au plus récent de chaque branche pour éviter de récupérer par exemple les 600 tags des deux plugins Formidable et Saisies. Cet exemple est donc à éviter car même en faisant cela il y a déjà 90 tags pour formidable car 90 branches x.y ! (faudrait peut être songer à virer des tags si c’est possibles).
Cela nous a permis de diminuer la taille du archives.xml principal qui était passé de 3,5M à 10,5M. On est actuellement à 4,5M (pour info celui du core était passé à 33M).
Pour y arriver on a supprimé aussi des informations inutilisées ou redondantes dans le xml comme la liste des autorisations et les traductions redondantes des zips d’un même plugin.
Cela aura quand même des effet sur SVP/Plugins SPIP mais qui sont minimes:
les traductions ne seront visibles que pour le zip le plus récent (Plugins SPIP). C’était d’ailleurs inutile de les répéter à chaque fois, il faudra proposer un nouvel affichage des pages plugin.
dans l’admin des plugins pour les branches 3.0 et 3.1 on pourra avoir une absence des logos. Cela a été patché pour 3.2 et 3.3 uniquement.
Tout nous parait donc prêt pour commencer à basculer.
Alors on bascule ?
PS :
Et pour celles et ceux qui ont oublié de tagguer correctement leur
projet. On a un outil qui permet de détecter tous les changements de
version écrits dans paquet et plugin.xml et d'en faire de beaux tags
git.
Et pour celles et ceux qui ont oublié de tagguer correctement leur
projet. On a un outil qui permet de détecter tous les changements de
version écrits dans paquet et plugin.xml et d'en faire de beaux tags
git.
Je n'ai jamais tagué les plugins sur lesquels je bosse jusqu'à présent
et à ma connaissance ça n'était pas incorrect.
Qu'est ce que c'est donc que taguer correctement un projet ?
Justement Maieul a utilisé l’outil sur formidable et saisies et on se retrouve avec 600zips à gérer rien que pour ces 2 projets, donc c’est pas vraiment génial de le faire tourner sur des projets et on peut pas conseiller ça.
Ou alors il faut revoir l’outil pour qu’il soit moins verbeux et ne pose que les tags sur les dernières versions majeures par exemple ?
Sur le dernier Y.Z de chaque X.Y.Z ?
Charge au mainteneur d’ajouter les autres tags importants à la main ?
Un tag c’est juste un pointeur sur une version qui en gros dira « là ça marche, on peut l’utiliser ».
On tag pas forcément chaque version : quand on est sur le dev d’un plugin on incrémente les versions plusieurs fois en fonction des changements, on test, on debug, on réitère et quand ça semble stabilisé prêt à l’utilisation, hop on pose un tag.
La commande c’est juste
git tag <lenomdutag>
et donc la bonne pratique est de taguer simplement avec le numéro de version :
git tag v1.2.3
L’avantage aussi c’est que tant que tu tag pas c’est pas dans un zip.
Donc tu as moins la pression de diffuser des bugs quand tu interviens sur un projet
Non attention, ce que tu as fait c’est une Release, pas un tag
La release c’est pour emballer le tag avec un petit texte (genre un changelog),
et quand tu fais la release tu mentionne un tag que tu dois déjà avoir posé.
Je dirais aussi qu’il faut revoir la notion des numéros de versions des plugins (le .z surtout, mais aussi parfois le .y).
Actuellement certain·e·s incrémentent la version à chaque commit, ce qui a peu de sens (en tout cas sous git avec des tags possibles).
Une nouvelle version n’a pas lieu d’être créée à chaque commit ; seulement quand on juge intéressant de proposer une nouvelle version à télécharger, qui peut donc être un ensemble de corrections (.z), ou un ensemble d’ajouts fonctionnels (.y).
Avec Cédric nous avons testé hier et aujourd'hui un nouvel outil destiné à remplacer smart-paquets et surtout à faciliter la transition douce vers les zips de git (moi j'ai juste testé hein).
Après relecture de toutes les réponses sur la partie tag, j’avoue que c’est toujours pas très clair pour moi sur ce que ça implique concrètement quand on maintient un plugin.
Je crois que la confusion pour ma part vient du fait qu’à la base un tag sert juste à signaler une version (le truc de base de git, et c’est normal qu’il y en ait moults), mais donc là ça pourrait amener à flooder le débardeur, même s’il se retreint au dernier tag d’une branche X.Y, c’est ça ?
Dans ce cas quelle est la bonne pratique pour taguer les dépôts ?
Des questions plus précises :
« il faut revoir l’outil pour qu’il […] ne pose que les tags sur les dernières versions » : un truc m’échappe, ça n’est pas toujours aux mainteneurs de poser les tags ? Ça veut dire que le débardeur en pose lui-même ?
Pour que le débardeur reconnaisse la version x.y.z à partir d’un tag, est-ce qu’il faut respecter une certaine nomenclature ? “v1.2.3”, ou juste “1.2.3”, ou autre ?
Mettons que pour un plugin, je ne veuille proposer qu’un seul zip par branche X : je fais comment ?
Exemple : il y a déjà des tags v1.0.x et j’ajoute un tag v1.1.0 suite à une nouvelle fonctionnalité → je supprime tous les anciens tag v1.1.x ?
Comme la méthode pour poser les tags semble propre à l’écosystème de SPIP, amha il faudrait bien documenter et clarifier avant de basculer, avec des exemples etc.
Petite piqure de rappel pour que la communauté SPIP pense à rester
inclusive, surtout en ce temps de confinement où les violences contre
les femmes ont redoublées et que la tendance médiatique est à réamorçer
la pompe du conformisme et du sexisme (en temps de guerre etc)
Ne tombez pas dans le piège, posez-vous des questions simples, par
exemple est-ce que vous allez vraiment pouvoir titrer "tout·es en
débardeur ?"
1) « il faut revoir l’outil pour qu’il [...] ne pose que les tags sur les dernières versions » : un truc m'échappe, ça n'est pas toujours aux mainteneurs de poser les tags ? Ça veut dire que le débardeur en pose lui-même ?
On parlait de l’outil que Camille propose pour taguer a posteriori tous les projets qu’on a importé sur la zone, mais qui est trop verbeux
2) Pour que le débardeur reconnaisse la version x.y.z à partir d'un tag, est-ce qu'il faut respecter une certaine nomenclature ? "v1.2.3", ou juste "1.2.3", ou autre ?
Oui c'est la nomenclature conventionnelle utilisée sur github et pour les projets composer etc. Le v est optionnel, les 2 formes sont supportées
3) Mettons que pour un plugin, je ne veuille proposer qu'un seul zip par branche X : je fais comment ?
Exemple : il y a déjà des tags v1.0.x et j'ajoute un tag v1.1.0 suite à une nouvelle fonctionnalité → je supprime tous les anciens tag v1.1.x ?
Un tag est éternel : une fois posé il sera là pour toujours, inaliénable, non modifiable
Quand tu veux diffuser une nouvelle version de ton plugin tu poses un nouveau tag et puis c'est tout. Un nouveau zip sera proposé, l'ancien continuera à exister, mais il ne sera plus proposé (il sera peut-être indexé dans le archives.xml selon l'incrément de numéro, mais de toute façon SVP va te proposer que la version la plus récente compatible)
La méthode pour poser des tags n'a rien de propre à SPIP, c'est totalement la même convention qui est utilisé sur github, dans l'univers composer etc...
Après relecture de toutes les réponses sur la partie tag, j’avoue que c’est toujours pas très clair pour moi sur ce que ça implique concrètement quand on maintient un plugin.
Je crois que la confusion pour ma part vient du fait qu’à la base un tag sert juste à signaler une version (le truc de base de git, et c’est normal qu’il y en ait moults), mais donc là ça pourrait amener à flooder le débardeur, même s’il se retreint au dernier tag d’une branche X.Y, c’est ça ?
Dans ce cas quelle est la bonne pratique pour taguer les dépôts ?
Je pense que comme le dit Matthieu, ça vient du fait qu’avec la pratique de la Zone on a souvent confondu je commite avec je publie une nouvelle version. Erreur qui a surement été amplifiée par les légendes urbaines sur SVP et ses mises à jour.
Donc maintenant avec Gitea on a plusieurs possibilités qui sont faciles d’accès :
créer une branche
poser des tags
et définir une version (au sens release).
sachant que le paquet.xml contient le numéro de version du plugin.
Il est donc important de savoir comment on manipule tout ça aujourd’hui dans l’optique de Gitea et du Débardeur.
Des questions plus précises :
« il faut revoir l’outil pour qu’il […] ne pose que les tags sur les dernières versions » : un truc m’échappe, ça n’est pas toujours aux mainteneurs de poser les tags ? Ça veut dire que le débardeur en pose lui-même ?
Non, c’est la phase 1 dont j’ai parlé plus haut : la migration de la zone vers le Gitea.
Après normalement on pose les tags au fur et à mesure de de développement selon une stratégie à expliquer.
Pour que le débardeur reconnaisse la version x.y.z à partir d’un tag, est-ce qu’il faut respecter une certaine nomenclature ? « v1.2.3 », ou juste « 1.2.3 », ou autre ?
Oui, vx.y.z ou x.y.z.
Mettons que pour un plugin, je ne veuille proposer qu’un seul zip par branche X : je fais comment ?
Exemple : il y a déjà des tags v1.0.x et j’ajoute un tag v1.1.0 suite à une nouvelle fonctionnalité → je supprime tous les anciens tag v1.1.x ?
Tu ne peux pas supprimer les tags.
Si on parle du débardeur aujourd’hui il prend uniquement le tag « max » de chaque branche x.y.
Le problème c’est que l’on utilise souvent le z et le y lors des mises à jour régulières des plugins, ce qui fait qu’on a pas mal de x.y différents.
Je me demande si il ne faudrait pas utiliser la notion de version (ou release) pour filtrer un peu les tags ?
Je rappelle quand même le fil c’est aussi de décider si on bascule sur le débardeur pour commencer à voir ces effets sur notre écosystème ?
Donc maintenant avec Gitea on a plusieurs possibilités qui sont faciles d'accès :
- créer une branche
- poser des tags
- et définir une version (au sens release).
sachant que le paquet.xml contient le numéro de version du plugin.
Les notions de tags et de versions ne sont pas super claires pour moi.
Les tags je vois bien (git tag), mais les versions ce serait un truc propre à Gitea ?
Je rappelle quand même le fil c'est aussi de décider si on bascule sur le débardeur pour commencer à voir ces effets sur notre écosystème ?
Je pensais que le débardeur était un script, et je l'ai d'abord cherché dans spip-contrib-outils
