Re: tag, git

Hello,

J’ai supprimé le 4.2.7 hier justement :p

Et oui c’était aussi ce que je voulais dire, on a pas vocation à faire un tag à chaque commit ou changement de version dans le xml sur la branche de dev, d’autant plus que ce n’est pas une branche distribuée.

Le tag est vraiment lié à la notion de distribution : « ok là le lot de commits que j’ai envoyé est cohérent et utilisable, on peut le distribuer »

--
Cédric
Le 21 juil. 2020 à 19:33 +0200, Bruno Bergot <[email protected]>, a écrit :
> Hop,
>
> Le 19/07/2020 à 17:50, Franck a écrit :
> > Hello 😊
> >
> > Je pense qu’il y a un problème avec les tags exemple :
> >
> > https://git.spip.net/spip/medias#
> >
> > * Il y a un tag 4.2.7 qui ne devrait pas exister
> > * Il manque le tag de la version 2.27.1
> >
> >
>
> Aucune trace de la 4.2.7 dans les pages de
> https://git.spip.net/spip/medias/releases et depuis ma copie locale, cf
> le retour de git ls-remote --tags origin
>
> La 2.27.1 a été introduite dans le paquet.xml par une de tes merge
> request cf
> https://git.spip.net/spip/medias/commit/5bdb2f9e6088ec0d109dc249796eb02cc7e9cb79
>
> Cela pose une question : faut-il introduire des changements de version
> de paquet.xml dans les merge request ?
>
> En effet, si on fait ça, la personne qui fait le merge devra ne pas
> oublier de générer le tag correspondant, et donc elle risque d'oublier
> de le faire, ce qui m'est arrivé sur ce cas précis.
>
> Je ne crois pas qu'on puisse ajouter la création d'un tag dans merge
> request, et même si c'était possible, je pense que c'est une mauvaise
> idée, tout comme y introduire le changement de version dans le
> paquet.xml. Car si la merge request existe depuis longtemps, et qu'entre
> temps la source a changé de version, la merge request va se retrouver en
> conflit.
>
> Amha, il faut laisser le soin aux personnes qui maintiennent le
> repo/projet de gérer les sauts de version et les créations de tags qui
> vont avec, ainsi on élimine le problème précédent, et surtout on ne
> release pas à chaque commit ou merge request. Perso, c'est ce que je
> fais sur pas mal de projets que je maintiens en dehors de SPIP, ce qui
> permet d'éviter les oups de release, et les sauts de versions répétitifs.
>
> Vos avis sur la question ?
>
>
> >
> >
> > Après, il y a eu de pas mal de changements dans les plugins-dist, sans avoir droit à un z+1, ce qui fait que pour le support, cela va franchement être complexe…
> >
> > Dans l’état actuel, je propose que l’on fasse un z+1 à tous les plugins-dist et un nouveau tag ! Afin de repartir sur une bonne base.
> >
>
> Justement non :)
>
> ++
> b_b
> _______________________________________________
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip