[spip-dev] tag, git

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.

Maintenant que nous somme sous git, concernant salvatore, il faudra faire un z+1 au paquet.xml et un tag juste avant la sorti de spip 3.3 ou pas ?

Franck

b_b · Juillet 21, 2020, 5:33

Hop,

Hello

Je pense qu’il y a un problème avec les tags exemple :

spip / medias · GitLab

* 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 Connexion · GitLab 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 - Mise à jour de la lib getid3 en 1.9.20, nous étions en 1.9.18 (5bdb2f9e) · Validations · spip / medias · GitLab

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

cerdic · Juillet 22, 2020, 6:21

Hello,

J’ai supprimé le 4.2.7 hier justement

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 »

Franck · Juillet 22, 2020, 7:02

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…