Re: Tous en débardeur !

Cerdic <[email protected]>
Newsgroups gmane.comp.web.spip.devel
Message-ID <9bbe2bd6-5f21-4d90-bd2d-98be32f684f5@Spark>
> 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 <[email protected]>, 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.