Re: [spip-dev] Tous en débardeur !

2020-04-05 Par sujet Cerdic
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 , 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

Re: [spip-dev] Tous en débardeur !

2020-04-04 Par sujet Gildas Cotomale
>> Les tags je vois bien (git tag), mais les versions ce serait un truc
>> propre à Gitea ?
>>
>
> Non c'est propre à toutes les forges : release sur github par exemple.

Pas toutes les forges… Je n'ai pas souvenir d'avoir vu ça dans Trac
(et ne pas confondre avec Svn car il peut se brancher sur Git aussi
d'une part, et que Sourceforge qui s'appuie sur Svn a cette notion de
release à travers la page de téléchargement de chaque projet) ni dans
Gogs (le frère aîné de Gitea) Mais cette précision est sans
importance.

> En fait ça permet de faire ton changelog de tes tags, enfin c'est un peu 
> comme ça que je le comprends.
> Pour l'instant on ne l'utilise pas avec le débardeur.
>
Le mot indique la "livraison/sortie" d'une nouvelle "mouture/version" ;
cf. [en anglais] https://searchsoftwarequality.techtarget.com/definition/release
& [en anglais] https://en.wikipedia.org/wiki/Software_release_life_cycle
(notions de RC et SR, ainsi que GA et EOL)

Les forges, de plus en plus, permettent de faire une release à partir d'un tag.
On va associer en effet un texte de "quoi de neuf" ou une synthèse des
changements significatifs (un vrai fichier d'historique/changelog
pouvant être disponible dans les dépôts) avec les sources [qui souvent
peuvent être téléchargé directement sans passer par ce biais --mais
c'est plus facile pour les usagers finaux] et d'autres fichiers…
En effet, on peut associer aux releases des binaires construits pour
cette sortie (si on a mis en place un mécanisme de CI-CD) et ceux-ci
peuvent être hébergés par la forge [dans ce cas c'est un espace dédié,
comme le files.spip.net, et non dans le dépôt] ou ailleurs. cf [en
anglais] https://stackoverflow.com/a/33587799/1699311
Les "assets" construits/générés, et/ou les parties du dépôt ayant
servi à leur création peuvent être vu comme les "artéfacts"

ailleurs  ;-)

Noter qu'on peut supprimer (et refaire) une "release", mettre à jour
sa note, mais qu'on ne peut supprimer un "tag"
>
>>
>> > 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 ?
>>
>> Je pensais que le débardeur était un script, et je l'ai d'abord cherché
>> dans spip-contrib-outils
>>
>> En fait, c'est un plugin qui est ici :
>> https://git.spip.net/spip-contrib-extensions/debardeur
>>
Ah merci. Je me demandais où était ce truc que je ne suis pas parvenu
à trouver sur Wikipedia comme annoncé.
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

Re: [spip-dev] Tous en débardeur !

2020-04-04 Par sujet Gildas Cotomale
Le mer. 1 avr. 2020 à 13:25, Eric Lupinacci a écrit :
>
> Yop,
>
> Le mer. 1 avr. 2020 à 12:03, Charles Razack  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

Re: [spip-dev] Tous en débardeur !

2020-04-04 Par sujet Cerdic
Les zips venant du trunk ou autre branches sont ceux de smart-paquet, et donc a 
supprimer oui.
Il n’y a pas d’archivelist pour le debardeur (il prend tous les projets 
hébergés par git.spip.net) sauf pour les externals.

On va créer un projet archivelist dans lequel on retrouvera aussi les fichiers 
traductions.txt de salvatore

--
Cédric
Le 3 avr. 2020 à 15:55 +0200, Maïeul Rouquette , a écrit :
> Le 31/03/2020 à 21:05, Eric Lupinacci a écrit :
> >
> >
> Questions betes
> sur
> https://plugins.spip.net/saisies.html?var_mode=calcul
>
> je vois
> 1. Des zip produit par tags
> 2. Des zip produits sur la dernière version du master
>
> On est d'accord qu'àa terme on virera le archivelist.txt et qu'on
> prendra le nouveau? Qui sera posé où ?
>
> Autre chose, je sais pas si c'est lié, mais sur plugins.spip.net, il n'y
> a plus de lien vers le code... dommage c'était parfois utile.
>
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Tous en débardeur !

2020-04-03 Par sujet Eric Lupinacci
Non mais en l'occurrence c'est pas pour demain.
Donc pour l'instant il faut bien le maintenir et de toute façon Contrib ne
fera que reproduire ce qu'il y a sur Plugins SPIP.

++
Eric


Le ven. 3 avr. 2020 à 17:26, teamspipfact...@gmail.com <
teamspipfact...@gmail.com> a écrit :

>
>
> Le 03/04/2020 à 15:55, Maïeul Rouquette a écrit :
>
> Le 31/03/2020 à 21:05, Eric Lupinacci a écrit :
>
> Hello,
>
> Avec Cédric nous avons testé hier et aujourd'hui un nouvel outil destiné à
> remplacer smart-paquets et surtout à faciliter la transition douce vers les
> zips de git (moi j'ai juste testé hein).
> Cet outil est nommé débardeur, je vous laisse consulter wikipedia pour
> l'explication.
>
> L'intérêt est que le débardeur est facile d'installation et de
> manipulation et permet de reconstituer les zips, les logos et les
> archives.xml à l'identique de smart-paquets.
> Il est même capable d'agréger dans un même dépôt SVP des zips Zone et des
> zips Gitea.
> De fait, il est possible de basculer petit à petit (mais pas trop quand
> même) des zips SP (qui consomment de la charge serveur) vers les zips Gitea
> qui existent une fois pour toute.
>
> Le débardeur se base sur les tags uniquement !
> Donc pas de tag Git, pas de débardeur.
> Pas de débardeur... pas de débardeur.
>
> Pour basculer les zips d'un plugins zone vers gitea, il faut que le plugin
> soit transféré sur Gitea (c'est aujourd'hui le cas de 90% des plugins
> compatibles SPIP 3.0 à 3.2) et qu'il existe des tags correspondants aux
> zips à fournir. On peut alors supprimer les lignes correspondantes du
> archivelist, le débardeur lit tous les repos des organisations Gitea (et
> même plus si besoin, le détail est dans le readme).
> Simple et de bon goût.
>
> Néanmoins, concernant les tags nous avons du limiter les tags au plus
> récent de chaque branche pour éviter de récupérer par exemple les 600 tags
> des deux plugins Formidable et Saisies. Cet exemple est donc à éviter car
> même en faisant cela il y a déjà 90 tags pour formidable car 90 branches
> x.y ! (faudrait peut être songer à virer des tags si c'est possibles).
> Cela nous a permis de diminuer la taille du archives.xml principal qui
> était passé de 3,5M à 10,5M. On est actuellement à 4,5M (pour info celui du
> core était passé à 33M).
> Pour y arriver on a supprimé aussi des informations inutilisées ou
> redondantes dans le xml comme la liste des autorisations et les traductions
> redondantes des zips d'un même plugin.
>
> Cela aura quand même des effet sur SVP/Plugins SPIP mais qui sont minimes:
> - les traductions ne seront visibles que pour le zip le plus récent
> (Plugins SPIP). C'était d'ailleurs inutile de les répéter à chaque fois, il
> faudra proposer un nouvel affichage des pages plugin.
> - dans l'admin des plugins pour les branches 3.0 et 3.1 on pourra avoir
> une absence des logos. Cela a été patché pour 3.2 et 3.3 uniquement.
>
> Tout nous parait donc prêt pour commencer à basculer.
> Alors on bascule ?
>
> A vous lire
>
> ++
> Eric
>
> Questions betes
> sur
> https://plugins.spip.net/saisies.html?var_mode=calcul
>
> je vois
> 1. Des zip produit par tags
> 2. Des zip produits sur la dernière version du master
>
> On est d'accord qu'àa terme on virera le archivelist.txt et qu'on prendra
> le nouveau? Qui sera posé où ?
>
> *Autre chose, je sais pas si c'est lié, mais sur plugins.spip.net
> , il n'y a plus de lien vers le code... dommage
> c'était parfois utile. *
>
>
> Juste pour ma gouverne, je penser avoir lu qu'avec la refonte de
> spipcontrib , plugin spip devais disparaître.
> j'ai rêver ?
>
>
> -- spipfactory.fr
> 
> Perdu dans la Galaxie SPIP ?https://boussole.spip.net/https://git.spip.net/
>
> Le 1er juillet 2001 : SPIP 1.0   est lancé officiellement.
> Le 1er juillet 2020 : SPIP 3.3.0 "that is the question"
>
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Tous en débardeur !

2020-04-03 Par sujet teamspipfact...@gmail.com



Le 03/04/2020 à 15:55, Maïeul Rouquette a écrit :

Le 31/03/2020 à 21:05, Eric Lupinacci a écrit :

Hello,

Avec Cédric nous avons testé hier et aujourd'hui un nouvel outil 
destiné à remplacer smart-paquets et surtout à faciliter la 
transition douce vers les zips de git (moi j'ai juste testé hein).
Cet outil est nommé débardeur, je vous laisse consulter wikipedia 
pour l'explication.


L'intérêt est que le débardeur est facile d'installation et de 
manipulation et permet de reconstituer les zips, les logos et les 
archives.xml à l'identique de smart-paquets.
Il est même capable d'agréger dans un même dépôt SVP des zips Zone et 
des zips Gitea.
De fait, il est possible de basculer petit à petit (mais pas trop 
quand même) des zips SP (qui consomment de la charge serveur) vers 
les zips Gitea qui existent une fois pour toute.


Le débardeur se base sur les tags uniquement !
Donc pas de tag Git, pas de débardeur.
Pas de débardeur... pas de débardeur.

Pour basculer les zips d'un plugins zone vers gitea, il faut que le 
plugin soit transféré sur Gitea (c'est aujourd'hui le cas de 90% des 
plugins compatibles SPIP 3.0 à 3.2) et qu'il existe des tags 
correspondants aux zips à fournir. On peut alors supprimer les lignes 
correspondantes du archivelist, le débardeur lit tous les repos des 
organisations Gitea (et même plus si besoin, le détail est dans le 
readme).

Simple et de bon goût.

Néanmoins, concernant les tags nous avons du limiter les tags au plus 
récent de chaque branche pour éviter de récupérer par exemple les 600 
tags des deux plugins Formidable et Saisies. Cet exemple est donc à 
éviter car même en faisant cela il y a déjà 90 tags pour formidable 
car 90 branches x.y ! (faudrait peut être songer à virer des tags si 
c'est possibles).
Cela nous a permis de diminuer la taille du archives.xml principal 
qui était passé de 3,5M à 10,5M. On est actuellement à 4,5M (pour 
info celui du core était passé à 33M).
Pour y arriver on a supprimé aussi des informations inutilisées ou 
redondantes dans le xml comme la liste des autorisations et les 
traductions redondantes des zips d'un même plugin.


Cela aura quand même des effet sur SVP/Plugins SPIP mais qui sont 
minimes:
- les traductions ne seront visibles que pour le zip le plus récent 
(Plugins SPIP). C'était d'ailleurs inutile de les répéter à chaque 
fois, il faudra proposer un nouvel affichage des pages plugin.
- dans l'admin des plugins pour les branches 3.0 et 3.1 on pourra 
avoir une absence des logos. Cela a été patché pour 3.2 et 3.3 
uniquement.


Tout nous parait donc prêt pour commencer à basculer.
Alors on bascule ?

A vous lire

++
Eric


Questions betes
sur
https://plugins.spip.net/saisies.html?var_mode=calcul

je vois
1. Des zip produit par tags
2. Des zip produits sur la dernière version du master

On est d'accord qu'àa terme on virera le archivelist.txt et qu'on 
prendra le nouveau? Qui sera posé où ?


*Autre chose, je sais pas si c'est lié, mais sur plugins.spip.net, il 
n'y a plus de lien vers le code... dommage c'était parfois utile. *




Juste pour ma gouverne, je penser avoir lu qu'avec la refonte de 
spipcontrib , plugin spip devais disparaître.

j'ai rêver ?


--
spipfactory.fr

Perdu dans la Galaxie SPIP ?
https://boussole.spip.net/
https://git.spip.net/

Le 1er juillet 2001 : SPIP 1.0   est lancé officiellement.
Le 1er juillet 2020 : SPIP 3.3.0 "that is the question"

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Tous en débardeur !

2020-04-03 Par sujet Maïeul Rouquette

Le 31/03/2020 à 21:05, Eric Lupinacci a écrit :

Hello,

Avec Cédric nous avons testé hier et aujourd'hui un nouvel outil destiné 
à remplacer smart-paquets et surtout à faciliter la transition douce 
vers les zips de git (moi j'ai juste testé hein).
Cet outil est nommé débardeur, je vous laisse consulter wikipedia pour 
l'explication.


L'intérêt est que le débardeur est facile d'installation et de 
manipulation et permet de reconstituer les zips, les logos et les 
archives.xml à l'identique de smart-paquets.
Il est même capable d'agréger dans un même dépôt SVP des zips Zone et 
des zips Gitea.
De fait, il est possible de basculer petit à petit (mais pas trop quand 
même) des zips SP (qui consomment de la charge serveur) vers les zips 
Gitea qui existent une fois pour toute.


Le débardeur se base sur les tags uniquement !
Donc pas de tag Git, pas de débardeur.
Pas de débardeur... pas de débardeur.

Pour basculer les zips d'un plugins zone vers gitea, il faut que le 
plugin soit transféré sur Gitea (c'est aujourd'hui le cas de 90% des 
plugins compatibles SPIP 3.0 à 3.2) et qu'il existe des tags 
correspondants aux zips à fournir. On peut alors supprimer les lignes 
correspondantes du archivelist, le débardeur lit tous les repos des 
organisations Gitea (et même plus si besoin, le détail est dans le readme).

Simple et de bon goût.

Néanmoins, concernant les tags nous avons du limiter les tags au plus 
récent de chaque branche pour éviter de récupérer par exemple les 600 
tags des deux plugins Formidable et Saisies. Cet exemple est donc à 
éviter car même en faisant cela il y a déjà 90 tags pour formidable car 
90 branches x.y ! (faudrait peut être songer à virer des tags si c'est 
possibles).
Cela nous a permis de diminuer la taille du archives.xml principal qui 
était passé de 3,5M à 10,5M. On est actuellement à 4,5M (pour info celui 
du core était passé à 33M).
Pour y arriver on a supprimé aussi des informations inutilisées ou 
redondantes dans le xml comme la liste des autorisations et les 
traductions redondantes des zips d'un même plugin.


Cela aura quand même des effet sur SVP/Plugins SPIP mais qui sont minimes:
- les traductions ne seront visibles que pour le zip le plus récent 
(Plugins SPIP). C'était d'ailleurs inutile de les répéter à chaque fois, 
il faudra proposer un nouvel affichage des pages plugin.
- dans l'admin des plugins pour les branches 3.0 et 3.1 on pourra avoir 
une absence des logos. Cela a été patché pour 3.2 et 3.3 uniquement.


Tout nous parait donc prêt pour commencer à basculer.
Alors on bascule ?

A vous lire

++
Eric


Questions betes
sur
https://plugins.spip.net/saisies.html?var_mode=calcul

je vois
1. Des zip produit par tags
2. Des zip produits sur la dernière version du master

On est d'accord qu'àa terme on virera le archivelist.txt et qu'on 
prendra le nouveau? Qui sera posé où ?


Autre chose, je sais pas si c'est lié, mais sur plugins.spip.net, il n'y 
a plus de lien vers le code... dommage c'était parfois utile.



___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Tous en débardeur !

2020-04-01 Par sujet Franck
Yop

C’est un très vieux sujet que j’avais soulever quand j’vais vu le premier cas 
sur la zone (faudrait faire une recherche dans les listes), perso, j’étais pour 
que nous restions sur le principe du x.y.z, et que concernant le numéro de 
version de la lib, il soit indiqué dans la description, mais la majorité des 
gens trouvaient que ce n’était pas pratique ou je ne sais plus quoi, le 
résultat, c’est que le consensus qui avait été trouver, était de faire un 
numéro de version à quatre chiffre.

 

Bref, perso, si cela fonctionnera avec les plugs en question, alors, c’est bon 

Pour les plugs, je pense qu’il s’agit des plugs qui sont sur gitea (possible 
que cela soit normal)

Exemple :

 

https://plugins.spip.net/saisies.html (on voit pleins de zip et pas le lien 
code source)

https://plugins.spip.net/facteur.html (il manque juste le lien code source)

 

Un plus qui fonctionne normalement et qui ne doit pas être sur gitea 
https://plugins.spip.net/cache_cool.html (j’ai pas vérifier)

Franck

 

De : Eric Lupinacci  
Envoyé : mercredi 1 avril 2020 18:39
À : Franck 
Cc : Charles Razack ; SPIP-Dev 
Objet : Re: [spip-dev] Tous en débardeur !

 

Hello,

 

Le mer. 1 avr. 2020 à 18:29, Franck mailto:spip.fra...@lien-d-amis.net> > a écrit :

Hello 

*   Juste pour dire que sur la zone, il y a des cas « particulier », il 
s’agit de plugs qui ne sont là que pour fournir une lib (il doit y en avoir 
beaucoup moins de 10 (possible 3 ou 4)).

Exemple : htmlpurifier 
https://plugins.spip.net/htmlpurifier.html?compatible_spip=3.2

C’était l’unique exception au format x.y.z 

Bref, c’est juste pour dire que le nouveau système doit en tenir compte, 
j’avais fait un ticket sur ce sujet https://core.spip.net/issues/4322

 

J'ai toujours été contre ce système.

Maintenant je ne sais pas ce que tu veux faire à ce propos.

On voit la version sur Plugins SPIP mais tu veux quoi d'autre ?

 

 

 

*   Enfin, une dernière chose, maintenant, sur plugin.spip, il y a des 
plug, ou il n’est plus possible de voir le lien vers le code du plug et en 
plus, maintenant, il y a un nouveau plug du nom de « spip » dans les « 30 plus 
utilisé en spip 3.2 » de la page https://plugins.spip.net :D

 

Faut nous donner les noms sinon je ne vois pas ce qu'on peut faire.

Pour spip je pense que c'est du au fait que dans l'organisation spip il y a 
spip et les plugins-dist.

 

++

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

Re: [spip-dev] Tous en débardeur !

2020-04-01 Par sujet Eric Lupinacci
Hello,

Le mer. 1 avr. 2020 à 18:29, Franck  a écrit :

> Hello 
>
>- Juste pour dire que sur la zone, il y a des cas « particulier », il
>s’agit de plugs qui ne sont là que pour fournir une lib (il doit y en avoir
>beaucoup moins de 10 (possible 3 ou 4)).
>
> Exemple : htmlpurifier
> https://plugins.spip.net/htmlpurifier.html?compatible_spip=3.2
>
> C’était l’unique exception au format x.y.z
>
> Bref, c’est juste pour dire que le nouveau système doit en tenir compte,
> j’avais fait un ticket sur ce sujet https://core.spip.net/issues/4322
>

J'ai toujours été contre ce système.
Maintenant je ne sais pas ce que tu veux faire à ce propos.
On voit la version sur Plugins SPIP mais tu veux quoi d'autre ?


>
>
>
>
>- Enfin, une dernière chose, maintenant, sur plugin.spip, il y a des
>plug, ou il n’est plus possible de voir le lien vers le code du plug et en
>plus, maintenant, il y a un nouveau plug du nom de « spip » dans les « 30
>plus utilisé en spip 3.2 » de la page https://plugins.spip.net :D
>
>
Faut nous donner les noms sinon je ne vois pas ce qu'on peut faire.
Pour spip je pense que c'est du au fait que dans l'organisation spip il y a
spip et les plugins-dist.

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

Re: [spip-dev] Tous en débardeur !

2020-04-01 Par sujet Franck
Hello 

*   Juste pour dire que sur la zone, il y a des cas « particulier », il 
s’agit de plugs qui ne sont là que pour fournir une lib (il doit y en avoir 
beaucoup moins de 10 (possible 3 ou 4)).

Exemple : htmlpurifier 
https://plugins.spip.net/htmlpurifier.html?compatible_spip=3.2

C’était l’unique exception au format x.y.z 

Bref, c’est juste pour dire que le nouveau système doit en tenir compte, 
j’avais fait un ticket sur ce sujet https://core.spip.net/issues/4322

 

 

*   Enfin, une dernière chose, maintenant, sur plugin.spip, il y a des 
plug, ou il n’est plus possible de voir le lien vers le code du plug et en 
plus, maintenant, il y a un nouveau plug du nom de « spip » dans les « 30 plus 
utilisé en spip 3.2 » de la page https://plugins.spip.net :D

 

Franck

 

De : Eric Lupinacci  
Envoyé : mercredi 1 avril 2020 13:25
À : Charles Razack 
Cc : SPIP-Dev 
Objet : Re: [spip-dev] Tous en débardeur !

 

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. 

 

 

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Tous en débardeur !

2020-04-01 Par sujet Charles Razack


Le 01/04/2020 à 12:59, Cerdic a écrit :
On parlait de l’outil que Camille propose pour taguer a posteriori 
tous les projets qu’on a importé sur la zone, mais qui est trop verbeux


Oups j'avais zappé le changement de sujet au cours de la discussion. Je 
me suis pas encore fait au changement d'heures, c'est dur le matin.

Ok si les remarques concernait l'outil de tag, c'est plus clair.


La méthode pour poser des tags n'a rien de propre à SPIP, c'est 
totalement la même convention qui est utilisé sur github, dans 
l'univers composer etc...


Oui mais je me demandais si le débardeur induisait une "restriction" à 
l'utilisation des tags justement. Donc à priori pas spécialement, joie.


Et bien c'est cool tout ça, incidemment ça va permettre de mettre les 
choses à plat pour l'utilisation branches et le versionnage des plugins.


J'avoue que j'avais tendance à me forcer à faire au minimum un +z à 
chaque commit pour je sais plus quelle raison au juste (force de 
l'habitude sur la zone ? légende urbaine pour la génération des zip ?). 
Mais du coup plus besoin de faire ainsi, ça peut attendre qu'il y ait un 
ensemble cohérents de commits qui correspondent vraiment à une montée de 
version avant de poser un tag.



___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Tous en débardeur !

2020-04-01 Par sujet nicod_

Le 01/04/2020 à 14:51, Eric Lupinacci a écrit :

C'est un plugin script qui utilise spip-cli.
Il n'est utile que sur le serveur de zips mais tu peux aussi l'essayer 
chez toi.
En fait, ça comble le manque de smart-paquets qui n'était utilisable que 
dans un contexte spip défini alors que chacun pouvait se construire un 
site comme plugins spip.


Ok, donc ça sera transparent côté utilisateurs, pour toutes les versions 
de SPIP si je comprends bien.


Donc pour en revenir à ta question, le débardeur tourne depuis quelques 
minutes sur le serveur de zips en cohabitation avec smart-paquets.
Il produit donc les archives.xml et il convient maintenant de tester que 
tous nos sites y compris Plugins SPIP se comportent comme avant coté SVP.


Du coup, on peut essayer, et j'imagine que c'est débrayable pour 
repasser à l'état actuel ?


--
nicod_
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Tous en débardeur !

2020-04-01 Par sujet Eric Lupinacci
Yo,

Le mer. 1 avr. 2020 à 14:42, nicod_  a écrit :

> Le 01/04/2020 à 13:25, Eric Lupinacci a écrit :
> > 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.
>
> Les notions de tags et de versions ne sont pas super claires pour moi.
>
> Les tags je vois bien (git tag), mais les versions ce serait un truc
> propre à Gitea ?
>
>
Non c'est propre à toutes les forges : release sur github par exemple.
En fait ça permet de faire ton changelog de tes tags, enfin c'est un peu
comme ça que je le comprends.
Pour l'instant on ne l'utilise pas avec le débardeur.



> > 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 ?
>
> Je pensais que le débardeur était un script, et je l'ai d'abord cherché
> dans spip-contrib-outils
>
> En fait, c'est un plugin qui est ici :
> https://git.spip.net/spip-contrib-extensions/debardeur
>
> Du coup, qu'est ce que ça signifie "basculer" ? ajouter le débardeur
> dans les plugins dist pour qu'il fasse partie de le distribution ?
>
> Ou bien ce serait à chacun dans son coin de se l'installer soi même ?
>
>
Non non tu ne fais rien ! ;)

C'est un plugin script qui utilise spip-cli.
Il n'est utile que sur le serveur de zips mais tu peux aussi l'essayer chez
toi.
En fait, ça comble le manque de smart-paquets qui n'était utilisable que
dans un contexte spip défini alors que chacun pouvait se construire un site
comme plugins spip.

Donc pour en revenir à ta question, le débardeur tourne depuis quelques
minutes sur le serveur de zips en cohabitation avec smart-paquets.
Il produit donc les archives.xml et il convient maintenant de tester que
tous nos sites y compris Plugins SPIP se comportent comme avant coté SVP.

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

Re: [spip-dev] Tous en débardeur !

2020-04-01 Par sujet nicod_

Le 01/04/2020 à 13:25, Eric Lupinacci a écrit :
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.


Les notions de tags et de versions ne sont pas super claires pour moi.

Les tags je vois bien (git tag), mais les versions ce serait un truc 
propre à Gitea ?


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 ?


Je pensais que le débardeur était un script, et je l'ai d'abord cherché 
dans spip-contrib-outils


En fait, c'est un plugin qui est ici : 
https://git.spip.net/spip-contrib-extensions/debardeur


Du coup, qu'est ce que ça signifie "basculer" ? ajouter le débardeur 
dans les plugins dist pour qu'il fasse partie de le distribution ?


Ou bien ce serait à chacun dans son coin de se l'installer soi même ?

--
nicod_
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Tous en débardeur !

2020-04-01 Par sujet Eric Lupinacci
Oui, Erational a créé le tag ensuite.
Et donc tu le vois maintenant :p.


++
Eric


Le mer. 1 avr. 2020 à 14:33, nicod_  a écrit :

> Le 01/04/2020 à 09:53, erational a écrit :
> > OK, Je me suis fait avoir comme un bleu :)
> > Je croyais à une mauvaise traduction mais c'est une autre feature.
> >
> > J'ai pigé.
> > Merci pour les précisions
>
> Moi j'ai pas pigé, ou alors le tag a été créé entre temps ?
>
> Parce que je le vois bien là maintenant.
>
> --
> nicod_
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip
>
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Tous en débardeur !

2020-04-01 Par sujet nicod_

Le 01/04/2020 à 09:53, erational a écrit :

OK, Je me suis fait avoir comme un bleu :)
Je croyais à une mauvaise traduction mais c'est une autre feature.

J'ai pigé.
Merci pour les précisions


Moi j'ai pas pigé, ou alors le tag a été créé entre temps ?

Parce que je le vois bien là maintenant.

--
nicod_
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Tous en débardeur !

2020-04-01 Par sujet Eric Lupinacci
Yop,

Le mer. 1 avr. 2020 à 12:03, Charles Razack  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
> ?
>
> 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.
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 ?

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

Re: [spip-dev] Tous en débardeur !

2020-04-01 Par sujet Cerdic
> 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 ?

On parlait de l’outil que Camille propose pour taguer a posteriori tous les 
projets qu’on a importé sur la zone, mais qui est trop verbeux
> 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 c'est la nomenclature conventionnelle utilisée sur github et pour les 
projets composer etc. Le v est optionnel, les 2 formes sont supportées


> 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 ?
Un tag est éternel : une fois posé il sera là pour toujours, inaliénable, non 
modifiable
Quand tu veux diffuser une nouvelle version de ton plugin tu poses un nouveau 
tag et puis c'est tout. Un nouveau zip sera proposé, l'ancien continuera à 
exister, mais il ne sera plus proposé (il sera peut-être indexé dans le 
archives.xml selon l'incrément de numéro, mais de toute façon SVP va te 
proposer que la version la plus récente compatible)

La méthode pour poser des tags n'a rien de propre à SPIP, c'est totalement la 
même convention qui est utilisé sur github, dans l'univers composer etc...

--
Cédric
Le 1 avr. 2020 à 12:03 +0200, Charles Razack , 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 ?
> Dans ce cas quelle est la bonne pratique pour taguer les dépôts ?
> Des questions plus précises :
> 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 ?
> 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 ?
> Comme la méthode pour poser les tags semble propre à l'écosystème de SPIP, 
> amha il faudrait bien documenter et clarifier avant de basculer, avec des 
> exemples etc.
> Le 01/04/2020 à 09:18, Cerdic a écrit :
> > Justement Maieul a utilisé l’outil sur formidable et saisies et on se 
> > retrouve avec 600zips à gérer rien que pour ces 2 projets, donc c’est pas 
> > vraiment génial de le faire tourner sur des projets et on peut pas 
> > conseiller ça.
> >
> > Ou alors il faut revoir l’outil pour qu’il soit moins verbeux et ne pose 
> > que les tags sur les dernières versions majeures par exemple ?
> > Sur le dernier Y.Z de chaque X.Y.Z ?
> >
> > Charge au mainteneur d’ajouter les autres tags importants à la main ?
> >
> > --
> > Cédric
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Tous en débardeur !

2020-04-01 Par sujet toutati
Hello,

bravo pour toutes ces belles avancées.

Petite piqure de rappel pour que la communauté SPIP pense à rester
inclusive, surtout en ce temps de confinement où les violences contre
les femmes ont redoublées et que la tendance médiatique est à réamorçer
la pompe du conformisme et du sexisme (en temps de guerre etc)

Ne tombez pas dans le piège, posez-vous des questions simples, par
exemple est-ce que vous allez vraiment pouvoir titrer "tout·es en
débardeur ?"

++

prenez soin de vous, et des autres.

touti

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Tous en débardeur !

2020-04-01 Par sujet Charles Razack
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 ?


Dans ce cas quelle est la bonne pratique pour taguer les dépôts ?

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 ?


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 ?


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 ?


Comme la méthode pour poser les tags semble propre à l'écosystème de 
SPIP, amha il faudrait bien documenter et clarifier avant de basculer, 
avec des exemples etc.


Le 01/04/2020 à 09:18, Cerdic a écrit :
Justement Maieul a utilisé l’outil sur formidable et saisies et on se 
retrouve avec 600zips à gérer rien que pour ces 2 projets, donc c’est 
pas vraiment génial de le faire tourner sur des projets et on peut pas 
conseiller ça.


Ou alors il faut revoir l’outil pour qu’il soit moins verbeux et ne 
pose que les tags sur les dernières versions majeures par exemple ?

Sur le dernier Y.Z de chaque X.Y.Z ?

Charge au mainteneur d’ajouter les autres tags importants à la main ?

--
Cédric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Tous en débardeur !

2020-04-01 Par sujet RealET

Eric Lupinacci a écrit le 31/03/2020 à 21:05 :

Hello,

Avec Cédric nous avons testé hier et aujourd'hui un nouvel outil destiné 
à remplacer smart-paquets et surtout à faciliter la transition douce 
vers les zips de git (moi j'ai juste testé hein).


\o/
Bravo et merci !

Est-ce qu'au passage, il résout ce vieux ticket
https://core.spip.net/issues/3927

?

À mettre aussi en relation avec
https://core.spip.net/issues/4150


--
RealET


___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Tous en débardeur !

2020-04-01 Par sujet Matthieu Marcillaud

Le 01/04/2020 à 09:18, Cerdic a écrit :
Justement Maieul a utilisé l’outil sur formidable et saisies et on se 
retrouve avec 600zips à gérer rien que pour ces 2 projets, donc c’est 
pas vraiment génial de le faire tourner sur des projets et on peut pas 
conseiller ça.


Ou alors il faut revoir l’outil pour qu’il soit moins verbeux et ne pose 
que les tags sur les dernières versions majeures par exemple ?

Sur le dernier Y.Z de chaque X.Y.Z ?


Je dirais aussi qu’il faut revoir la notion des numéros de versions des 
plugins (le .z surtout, mais aussi parfois le .y).


Actuellement certain·e·s incrémentent la version à chaque commit, ce qui 
a peu de sens (en tout cas sous git avec des tags possibles).


Une nouvelle version n’a pas lieu d’être créée à chaque commit ; 
seulement quand on juge intéressant de proposer une nouvelle version à 
télécharger, qui peut donc être un ensemble de corrections (.z), ou un 
ensemble d’ajouts fonctionnels (.y).


Et ça sera bien plus facile avec les tags en Git.

MM.
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Tous en débardeur !

2020-04-01 Par sujet erational

OK, Je me suis fait avoir comme un bleu :)
Je croyais à une mauvaise traduction mais c'est une autre feature.

J'ai pigé.
Merci pour les précisions



Le 01/04/2020 à 09:51, Cerdic a écrit :

Non attention, ce que tu as fait c’est une Release, pas un tag :p
La release c’est pour emballer le tag avec un petit texte (genre un 
changelog),
et quand tu fais la release tu mentionne un tag que tu dois déjà avoir 
posé.


Là regarde https://git.spip.net/spip-contrib-extensions/sociaux/releases
si je clique sur le tag il n’existe pas 
https://git.spip.net/spip-contrib-extensions/sociaux/src/tag/v2.2.0


Ou alors il y a une option quelque part qui manque, mais on a eu le 
même soucis en testant avec Eric


--
Cédric
Le 1 avr. 2020 à 09:42 +0200, erational , a 
écrit :

Gitea permet aussi de le faire directement en ligne sur la forge.

Sur chaque dépot, il y a un  onglet "version" qui permet de définir 
ses tags.


Je viens de tester:
https://git.spip.net/spip-contrib-extensions/sociaux/releases

Tou(te)s en débardeur !


Le 01/04/2020 à 09:22, Cerdic a écrit :
Un tag c’est juste un pointeur sur une version qui en gros dira « là 
ça marche, on peut l’utiliser ».
On tag pas forcément chaque version : quand on est sur le dev d’un 
plugin on incrémente les versions plusieurs fois en fonction des 
changements, on test, on debug, on réitère et quand ça semble 
stabilisé prêt à l’utilisation, hop on pose un tag.


La commande c’est juste
git tag 

et donc la bonne pratique est de taguer simplement avec le numéro de 
version :

git tag v1.2.3

L’avantage aussi c’est que tant que tu tag pas c’est pas dans un zip.
Donc tu as moins la pression de diffuser des bugs quand tu 
interviens sur un projet


--
Cédric
Le 31 mars 2020 à 22:12 +0200, JLuc , a écrit :

Le 31/03/2020 à 21:39, cam.la...@azerttyu.net a écrit :

gogogogo


certes


Et pour celles et ceux qui ont oublié de tagguer correctement leur
projet. On a un outil qui permet de détecter tous les changements de
version écrits dans paquet et plugin.xml et d'en faire de beaux tags
git.


Je n'ai jamais tagué les plugins sur lesquels je bosse jusqu'à présent
et à ma connaissance ça n'était pas incorrect.

Qu'est ce que c'est donc que taguer correctement un projet ?


JL

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


___
liste:https://listes.rezo.net/mailman/listinfo/spip-dev
doc:https://www.spip.net/
dev:https://core.spip.net/
irc://irc.freenode.net/spip


--
_
https://www.erational.org
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


--
_
https://www.erational.org

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Tous en débardeur !

2020-04-01 Par sujet Cerdic
Non attention, ce que tu as fait c’est une Release, pas un tag :p
La release c’est pour emballer le tag avec un petit texte (genre un changelog),
et quand tu fais la release tu mentionne un tag que tu dois déjà avoir posé.

Là regarde https://git.spip.net/spip-contrib-extensions/sociaux/releases
si je clique sur le tag il n’existe pas 
https://git.spip.net/spip-contrib-extensions/sociaux/src/tag/v2.2.0

Ou alors il y a une option quelque part qui manque, mais on a eu le même soucis 
en testant avec Eric

--
Cédric
Le 1 avr. 2020 à 09:42 +0200, erational , a écrit :
> Gitea permet aussi de le faire directement en ligne sur la forge.
>
> Sur chaque dépot, il y a un  onglet "version" qui permet de définir ses tags.
>
> Je viens de tester:
> https://git.spip.net/spip-contrib-extensions/sociaux/releases
>
> Tou(te)s en débardeur !
>
>
> Le 01/04/2020 à 09:22, Cerdic a écrit :
> > Un tag c’est juste un pointeur sur une version qui en gros dira « là ça 
> > marche, on peut l’utiliser ».
> > On tag pas forcément chaque version : quand on est sur le dev d’un plugin 
> > on incrémente les versions plusieurs fois en fonction des changements, on 
> > test, on debug, on réitère et quand ça semble stabilisé prêt à 
> > l’utilisation, hop on pose un tag.
> >
> > La commande c’est juste
> > git tag 
> >
> > et donc la bonne pratique est de taguer simplement avec le numéro de 
> > version :
> > git tag v1.2.3
> >
> > L’avantage aussi c’est que tant que tu tag pas c’est pas dans un zip.
> > Donc tu as moins la pression de diffuser des bugs quand tu interviens sur 
> > un projet
> >
> > --
> > Cédric
> > Le 31 mars 2020 à 22:12 +0200, JLuc , a écrit :
> > > Le 31/03/2020 à 21:39, cam.la...@azerttyu.net a écrit :
> > > > gogogogo
> > >
> > > certes
> > >
> > > > Et pour celles et ceux qui ont oublié de tagguer correctement leur
> > > > projet. On a un outil qui permet de détecter tous les changements de
> > > > version écrits dans paquet et plugin.xml et d'en faire de beaux tags
> > > > git.
> > >
> > > Je n'ai jamais tagué les plugins sur lesquels je bosse jusqu'à présent
> > > et à ma connaissance ça n'était pas incorrect.
> > >
> > > Qu'est ce que c'est donc que taguer correctement un projet ?
> > >
> > >
> > > JL
> > >
> > > ___
> > > liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> > > doc: https://www.spip.net/
> > > dev: https://core.spip.net/
> > > irc://irc.freenode.net/spip
> >
> > ___
> > liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> > doc: https://www.spip.net/
> > dev: https://core.spip.net/
> > irc://irc.freenode.net/spip
>
> --
> _
> https://www.erational.org
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Tous en débardeur !

2020-04-01 Par sujet Eric Lupinacci
Re,

Le mer. 1 avr. 2020 à 09:42, erational  a écrit :

> Gitea permet aussi de le faire directement en ligne sur la forge.
>
> Sur chaque dépot, il y a un  onglet "version" qui permet de définir ses
> tags.
>
> Je viens de tester:
> https://git.spip.net/spip-contrib-extensions/sociaux/releases
>
>
Euh, alors il faut faire attention qu'une version Gitea (ou release sur
Github) c'est pas un tag. Tu poser une version sans qu'il y ait de tag
attaché.
Et c'est ton cas : si tu vas dans l'onglet code et que tu ouvres la liste
des branches/tags tu vas voir que tu n'as aucun tag.
Pas de tag pas de zip.
Pas de zip... pas de zip.

++
Eric (qui s'est déjà fait avoir)
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Tous en débardeur !

2020-04-01 Par sujet Eric Lupinacci
Hello,

Si je prends l'exemple de formidable, il y avait 300 changement de versions
dans le paquet.xml que ce soit x, y ou z.
Mais il y a aussi 90 changements x.y, ce qui fait que même en prenant le
x.y.zmax on récupère 90 tags.
C'est pour ça que je ne suis pas sur qu'il faille même créer des tags à la
volée sur chaque x.y car la façon dont le y est utilisé est très
personnelle...

C'est pourquoi, je dirais qu'il faut agir en 2 étapes :
1- migrer les archivelist actuels en créant juste les tags nécessaires pour
reproduire les zips de la zone. Les contribs non transférées sur Gitea ne
sont pas concernées.
Si on peut aussi supprimer des zips inutiles allons-y. Je suis toujours
étonné de voir des chevauchements de branches spip entre plusieurs branches
du même plugin.

2- définir une logique de création de tag qui passera surement par une
logique de numérotation x.y.z et de gestion du master vs les branches.

++
Eric


Le mer. 1 avr. 2020 à 09:22, Cerdic  a écrit :

> Un tag c’est juste un pointeur sur une version qui en gros dira « là ça
> marche, on peut l’utiliser ».
> On tag pas forcément chaque version : quand on est sur le dev d’un plugin
> on incrémente les versions plusieurs fois en fonction des changements, on
> test, on debug, on réitère et quand ça semble stabilisé prêt à
> l’utilisation, hop on pose un tag.
>
> La commande c’est juste
> git tag 
>
> et donc la bonne pratique est de taguer simplement avec le numéro de
> version :
> git tag v1.2.3
>
> L’avantage aussi c’est que tant que tu tag pas c’est pas dans un zip.
> Donc tu as moins la pression de diffuser des bugs quand tu interviens sur
> un projet
>
> --
> Cédric
> Le 31 mars 2020 à 22:12 +0200, JLuc , a écrit :
>
> Le 31/03/2020 à 21:39, cam.la...@azerttyu.net a écrit :
>
> gogogogo
>
>
> certes
>
> Et pour celles et ceux qui ont oublié de tagguer correctement leur
> projet. On a un outil qui permet de détecter tous les changements de
> version écrits dans paquet et plugin.xml et d'en faire de beaux tags
> git.
>
>
> Je n'ai jamais tagué les plugins sur lesquels je bosse jusqu'à présent
> et à ma connaissance ça n'était pas incorrect.
>
> Qu'est ce que c'est donc que taguer correctement un projet ?
>
>
> JL
>
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip
>
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Tous en débardeur !

2020-04-01 Par sujet erational

Gitea permet aussi de le faire directement en ligne sur la forge.

Sur chaque dépot, il y a un  onglet "version" qui permet de définir ses 
tags.


Je viens de tester:
https://git.spip.net/spip-contrib-extensions/sociaux/releases

Tou(te)s en débardeur !


Le 01/04/2020 à 09:22, Cerdic a écrit :
Un tag c’est juste un pointeur sur une version qui en gros dira « là 
ça marche, on peut l’utiliser ».
On tag pas forcément chaque version : quand on est sur le dev d’un 
plugin on incrémente les versions plusieurs fois en fonction des 
changements, on test, on debug, on réitère et quand ça semble 
stabilisé prêt à l’utilisation, hop on pose un tag.


La commande c’est juste
git tag 

et donc la bonne pratique est de taguer simplement avec le numéro de 
version :

git tag v1.2.3

L’avantage aussi c’est que tant que tu tag pas c’est pas dans un zip.
Donc tu as moins la pression de diffuser des bugs quand tu interviens 
sur un projet


--
Cédric
Le 31 mars 2020 à 22:12 +0200, JLuc , a écrit :

Le 31/03/2020 à 21:39, cam.la...@azerttyu.net a écrit :

gogogogo


certes


Et pour celles et ceux qui ont oublié de tagguer correctement leur
projet. On a un outil qui permet de détecter tous les changements de
version écrits dans paquet et plugin.xml et d'en faire de beaux tags
git.


Je n'ai jamais tagué les plugins sur lesquels je bosse jusqu'à présent
et à ma connaissance ça n'était pas incorrect.

Qu'est ce que c'est donc que taguer correctement un projet ?


JL

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


--
_
https://www.erational.org

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Tous en débardeur !

2020-04-01 Par sujet Cerdic
Un tag c’est juste un pointeur sur une version qui en gros dira « là ça marche, 
on peut l’utiliser ».
On tag pas forcément chaque version : quand on est sur le dev d’un plugin on 
incrémente les versions plusieurs fois en fonction des changements, on test, on 
debug, on réitère et quand ça semble stabilisé prêt à l’utilisation, hop on 
pose un tag.

La commande c’est juste
git tag 

et donc la bonne pratique est de taguer simplement avec le numéro de version :
git tag v1.2.3

L’avantage aussi c’est que tant que tu tag pas c’est pas dans un zip.
Donc tu as moins la pression de diffuser des bugs quand tu interviens sur un 
projet

--
Cédric
Le 31 mars 2020 à 22:12 +0200, JLuc , a écrit :
> Le 31/03/2020 à 21:39, cam.la...@azerttyu.net a écrit :
> > gogogogo
>
> certes
>
> > Et pour celles et ceux qui ont oublié de tagguer correctement leur
> > projet. On a un outil qui permet de détecter tous les changements de
> > version écrits dans paquet et plugin.xml et d'en faire de beaux tags
> > git.
>
> Je n'ai jamais tagué les plugins sur lesquels je bosse jusqu'à présent
> et à ma connaissance ça n'était pas incorrect.
>
> Qu'est ce que c'est donc que taguer correctement un projet ?
>
>
> JL
>
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Tous en débardeur !

2020-04-01 Par sujet Cerdic
Justement Maieul a utilisé l’outil sur formidable et saisies et on se retrouve 
avec 600zips à gérer rien que pour ces 2 projets, donc c’est pas vraiment 
génial de le faire tourner sur des projets et on peut pas conseiller ça.

Ou alors il faut revoir l’outil pour qu’il soit moins verbeux et ne pose que 
les tags sur les dernières versions majeures par exemple ?
Sur le dernier Y.Z de chaque X.Y.Z ?

Charge au mainteneur d’ajouter les autres tags importants à la main ?

--
Cédric
Le 31 mars 2020 à 21:39 +0200, cam.la...@azerttyu.net , 
a écrit :
> gogogogo
>
> PS :
> Et pour celles et ceux qui ont oublié de tagguer correctement leur
> projet. On a un outil qui permet de détecter tous les changements de
> version écrits dans paquet et plugin.xml et d'en faire de beaux tags
> git.
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Tous en débardeur !

2020-03-31 Par sujet RastaPopoulos
Le 31/03/2020 à 21:39, cam.la...@azerttyu.net a écrit :
> Et pour celles et ceux qui ont oublié de tagguer correctement leur
> projet. On a un outil qui permet de détecter tous les changements de
> version écrits dans paquet et plugin.xml et d'en faire de beaux tags
> git.

C'est justement l'exemple que donne Éric pour Formidable et Saisies, et qu'il 
est conseillé de ne PAS faire.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Tous en débardeur !

2020-03-31 Par sujet JLuc

Le 31/03/2020 à 21:39, cam.la...@azerttyu.net a écrit :

gogogogo


certes


Et pour celles et ceux qui ont oublié de tagguer correctement leur
projet. On a un outil qui permet de détecter tous les changements de
version écrits dans paquet et plugin.xml et d'en faire de beaux tags
git.


Je n'ai jamais tagué les plugins sur lesquels je bosse jusqu'à présent
et à ma connaissance ça n'était pas incorrect.

Qu'est ce que c'est donc que taguer correctement un projet ?


JL

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Tous en débardeur !

2020-03-31 Par sujet cam.la...@azerttyu.net
gogogogo

PS :
Et pour celles et ceux qui ont oublié de tagguer correctement leur
projet. On a un outil qui permet de détecter tous les changements de
version écrits dans paquet et plugin.xml et d'en faire de beaux tags
git.
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


[spip-dev] Tous en débardeur !

2020-03-31 Par sujet Eric Lupinacci
Hello,

Avec Cédric nous avons testé hier et aujourd'hui un nouvel outil destiné à
remplacer smart-paquets et surtout à faciliter la transition douce vers les
zips de git (moi j'ai juste testé hein).
Cet outil est nommé débardeur, je vous laisse consulter wikipedia pour
l'explication.

L'intérêt est que le débardeur est facile d'installation et de manipulation
et permet de reconstituer les zips, les logos et les archives.xml à
l'identique de smart-paquets.
Il est même capable d'agréger dans un même dépôt SVP des zips Zone et des
zips Gitea.
De fait, il est possible de basculer petit à petit (mais pas trop quand
même) des zips SP (qui consomment de la charge serveur) vers les zips Gitea
qui existent une fois pour toute.

Le débardeur se base sur les tags uniquement !
Donc pas de tag Git, pas de débardeur.
Pas de débardeur... pas de débardeur.

Pour basculer les zips d'un plugins zone vers gitea, il faut que le plugin
soit transféré sur Gitea (c'est aujourd'hui le cas de 90% des plugins
compatibles SPIP 3.0 à 3.2) et qu'il existe des tags correspondants aux
zips à fournir. On peut alors supprimer les lignes correspondantes du
archivelist, le débardeur lit tous les repos des organisations Gitea (et
même plus si besoin, le détail est dans le readme).
Simple et de bon goût.

Néanmoins, concernant les tags nous avons du limiter les tags au plus
récent de chaque branche pour éviter de récupérer par exemple les 600 tags
des deux plugins Formidable et Saisies. Cet exemple est donc à éviter car
même en faisant cela il y a déjà 90 tags pour formidable car 90 branches
x.y ! (faudrait peut être songer à virer des tags si c'est possibles).
Cela nous a permis de diminuer la taille du archives.xml principal qui
était passé de 3,5M à 10,5M. On est actuellement à 4,5M (pour info celui du
core était passé à 33M).
Pour y arriver on a supprimé aussi des informations inutilisées ou
redondantes dans le xml comme la liste des autorisations et les traductions
redondantes des zips d'un même plugin.

Cela aura quand même des effet sur SVP/Plugins SPIP mais qui sont minimes:
- les traductions ne seront visibles que pour le zip le plus récent
(Plugins SPIP). C'était d'ailleurs inutile de les répéter à chaque fois, il
faudra proposer un nouvel affichage des pages plugin.
- dans l'admin des plugins pour les branches 3.0 et 3.1 on pourra avoir une
absence des logos. Cela a été patché pour 3.2 et 3.3 uniquement.

Tout nous parait donc prêt pour commencer à basculer.
Alors on bascule ?

A vous lire

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