Le mer. 1 avr. 2020 à 13:25, Eric Lupinacci a écrit :
>
> Yop,
>
> Le mer. 1 avr. 2020 à 12:03, 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 ?
>>
Tout "commit" Git est référencé par un haché (là où Subversion utilise
un numéro de commit)
Le "tag" Git permet de nommer un haché, i.e. poser une étiquette
synonyme de la longue référence hexadécimale interne. En tout cas
c'est ainsi que je l'utilise.

Ta version peut se composer de plusieurs commits, ce qui est
d'ailleurs mieux en terme de relecture-suivi-maintenance. En tout cas
j'ai toujours trouvé pénible de devoir faire une nouvelle version pour
chaque commit car j'aime avoir de petits commits pour résoudre un
souci ou ajouter une fonctionnalité. (Après, j'imagine que c'est lié
au mode de fonctionnement de Subversion et au nombre de personnes
participant… Avec Git le souci ne se pose plus car on poussera une
version qui pourra avoir plusieurs commits)

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

Quelles légendes par exemple ?
Il me semble que ce/cette choix/pratique existait bien avant SVP,
d'incrémenter "z" (probablement pour ne pas perdre les personnes qui
rafraichissent leur installation par un "svn co" ?)

> 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 :
>>
>> 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 ?
>
> 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.
>
>>
>> 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, vx.y.z ou x.y.z.
>
>
>>
>> 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 ?
>
> 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 ?
>
Oui, ce débardeur devrait s'appuyer sur les versions publiées et non les tags.
Idéalement, les deux se suivent, mais il peut arriver qu'on ait un tag
qui ne soit pas destinée à la publication du grand public
(contrairement aux releases)

> 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 ?
>
> ++
> Eric
_______________________________________________
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 à