Re: tag, git

Non, mais je comprends ce que vous voulez dire, et l’exemple parfait, c’est salvatore qui fait des commits mais dont les gens doivent attendre un up de version pour y avoir droit, mais ce qui se passe aussi, c’est qu’entre spip_loader qui ne fonctionne plus comme avant https://core.spip.net/issues/4530 :(

Et le fait que les nouveaux tags sont « rare » et bien cela ne va pas être simple pour faire des tests…

Ce week, je suis bon, pour refaire tous les tests que j’avais fait concernant php 8 car, je n’avais pas fait attention au changement de spip_loader…

 

 

De : Cerdic <[email protected]> 
Envoyé : mercredi 22 juillet 2020 08:21
À : Franck <[email protected]>; [email protected]; Bruno Bergot <[email protected]>
Objet : Re: [spip-dev] 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] <mailto:[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