> 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...

--
Cédric
Le 1 avr. 2020 à 12:03 +0200, Charles Razack <tchar...@bravecassine.com>, a 
écrit :
> 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 :
> 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 ?
> 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 ?
> 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.
> Le 01/04/2020 à 09:18, Cerdic a écrit :
> > 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 ?
> >
> > --
> > Cédric
> _______________________________________________
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip
_______________________________________________
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Répondre à