En choisissant de se baser sur les tags on ne fait qu’adopter la convention 
utilisée dans le monde composer/packagist dans lequel il suffit de tagguer son 
projet pour que le package composer soit mis à jour automatiquement sur 
packagist.

Dans la mesure où c’est la direction dans laquelle on veut aller, il me semble 
sain qu’on adopte la même convention, non ? Il serait un peu balot de définir 
un nouveau mode de fonctionnement collectif qu’on devra changer dans X mois 
parce que c’est pas la convention dans le monde composer...

A noter que sur github chaque tag est automatiquement une release, qu’on peut 
ensuite éditer d’un changelog etc.


Ce qu’on peut dire aussi sur les changement de numero de version, c’est 
qu’avant comme l’empaqueteur zippait des branches vivantes, chaque commit 
pouvait donc partir dans le zip et être installé chez quelqu’un.
C’est ce point qui rendait vraiment nécessaire le besoin d’incrémenter la 
version à chaque fois ou presque, pour avoir un peu de traçabilité.

C’est aussi la raison pour laquelle générer des tags a posteriori en se basant 
sur toutes les versions du paquet.xml est inutilement très verbeux…

Maintenant que seuls les tags seront publiés dans des zips il sera plus 
confortable de travailler sur un lot de modification sans forcément incrémenter 
aussi souvent le numéro de version, tester, et tagguer quand on pense que ça 
mérite d’être publié.

--
Cédric
Le 5 avr. 2020 à 02:07 +0200, Gildas Cotomale <gildas.cotom...@gmail.com>, a 
écrit :
> > >
> Je vais aller jeter un oeil, mais de ce que je lis c'est dommage que
> ça s'appuie sur les tags et non les releases.

_______________________________________________
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 à