[spip-dev] Gitea et le débardeur

Dev
1

Hello,

Je suis toujours embêté par notre méthode de génération des zips basés sur les composants x et y d’une version x.y.z.
On se retrouve avec des versions 3.11.1 et 3.12.1 par exemple visibles sur Plugins SPIP, accessibles indépendamment alors que dans ce cas, 3.12.1 est à utiliser préférentiellement.
On en vient à éviter de faire un y+1 pour ne pas avoir ce type de désagrément.
Et plus on va avancer, plus cela sera pénible.

Le fait de créer un tag git pour publier une version via le débardeur n’est pas à remettre en cause, ça me parait la bonne approche. En effet, on doit faire une action volontaire pour publier une version.
Mais le problème actuel c’est que “publier” équivaut à “distribuer” (zip, SVP et Plugins SPIP).
Or à mon avis il faudrait aussi avoir une possibilité de décider si une version publiée doit être distribuée.

Il existe sous Gitea une notion de version qui s’appuie sur les tags.
La version semble être un objet composé d’un titre, d’une description, d’un état et d’un tag.
Il est possible d’éditer cette version à tout moment et de la supprimer simplement en un clic.
Voir ici : https://git.spip.net/spip-contrib-extensions/rainette/releases
Il est impératif de mettre un titre à la version créée sinon elle n’est pas modifiable par la suite (voir 3.11.2 par exemple), sauf à la recréer avec le même tag.

De mon point de vue, cette notion de version correspond bien au besoin de distribution si on y liste que les versions à distribuer.
Si le débardeur lisait cette liste plutôt que les tags il pourrait ne produire que cette liste en zip.
Et si on supprime une version comme la v3.11.2 par exemple, cela ne modifie pas le tag qui reste utilisable via git si besoin mais ça retire la distribution du zip.

On pourrait peut-être évoluer vers cette logique petit à petit en modifiant le débardeur pour qu’il utilise d’abord les versions Gitea si disponibles et sinon les tags.

Qu’en pensez-vous ?

2

Si je comprend la distinction entre les deux notions, j'aurais deux remarques
1. Est-ce possible de d'éditer les releases gitea facilement en ligne de commande sans passer par du clicodrome
2. Est-ce que cela ne serait juste pas plus simple de se dire qu'on publie tous les tags, mais qu'on ne distribue que les plus récent, à savoir pour chaque x, celui ayant le plus haut y, et pour chaque y, celui ayant le plus grand z? Typiquement ce qu'on a retenu comme affichage sur contrib.spip.net, et que le débardeur devrait se contenter

L'avantage de la solution 2 est qu'elle est simple et uniforme.

3

Yop,

  1. Est-ce possible de d’éditer les releases gitea facilement en ligne de
    commande sans passer par du clicodrome

Je ne comprends pas le clicodrome (deux clics et une saisie).
Si c’est comme je pense une notion Gitea et pas git oui il faut passer par l’UI Gitea.
Mais Camille doit pouvoir te répondre mieux que moi.

  1. Est-ce que cela ne serait juste pas plus simple de se dire qu’on
    publie tous les tags, mais qu’on ne distribue que les plus récent, à
    savoir pour chaque x, celui ayant le plus haut y, et pour chaque y,
    celui ayant le plus grand z? Typiquement ce qu’on a retenu comme
    affichage sur contrib.spip.net, et que le débardeur devrait se contenter

Oui ça serait mieux mais alors pourquoi on ne le fait pas ?

Après c’est pas mal aussi la notion de version Gitea car on peut saisir du texte pour expliquer.
Je me suis rendu compte qu’on a aucun moyen simple de faire un changelog « plus disert » et plus compréhensible que les commits.

Quand je fais ça sur Contrib je me retrouve à mettre une liste bof bof dans l’article principal alors qu’il serait plus logique d’avoir un changelog explicatif dans un article à part.
En gros, on n’est pas prévenu des évolutions et si il faut prévenir d’un changement important on ne sait pas où le faire.

4

Yop,

Je ne comprends pas le clicodrome (deux clics et une saisie).
Si c'est comme je pense une notion Gitea et pas git oui il faut
passer par l'UI Gitea.
Mais Camille doit pouvoir te répondre mieux que moi.

bah c'est juste qu'au bout d'un moment, rajoutons une procédure
supplémentaire ca fini par demotiver. Mais bon si comme tu dis priorité
aux tags... go go

> 2. Est-ce que cela ne serait juste pas plus simple de se dire
> qu'on
> publie tous les tags, mais qu'on ne distribue que les plus récent
Oui ça serait mieux mais alors pourquoi on ne le fait pas ?

Ah ca je sais pas. Moi je suis pour !

Après c'est pas mal aussi la notion de version Gitea car on peut
saisir du texte pour expliquer.
Je me suis rendu compte qu'on a aucun moyen simple de faire un
changelog "plus disert" et plus compréhensible que les commits.
Quand je fais ça sur Contrib je me retrouve à mettre une liste bof
bof dans l'article principal alors qu'il serait plus logique d'avoir
un changelog explicatif dans un article à part.
En gros, on n'est pas prévenu des évolutions et si il faut prévenir
d'un changement important on ne sait pas où le faire.

Oui ca pourrait être effectivement pour moi la seule bonne raison :
avoir un système de changelog qui pourrait ensuite servir aussi lors de
la mise à jour via SVP et co.

5

Re,

Oui ca pourrait être effectivement pour moi la seule bonne raison :
avoir un système de changelog qui pourrait ensuite servir aussi lors de
la mise à jour via SVP et co.

Seule raison non.
Les trucs tout auto c’est bien mais y a des limites et la distribution des zips est à mon avis une limite quand on a aucune possibilité d’expliquer simplement les modifications. On a effectivement ce souci sur SVP et les updates y ou z.

Je viens de vérifier et l’API Gitea permet facilement de récupérer ces versions (appelées release en Gitea).
Il faut faire :

[https://git.spip.net/api/v1/repos/spip-contrib-extensions/rainette/releases?access_token=xxxx](https://git.spip.net/api/v1/repos/spip-contrib-extensions/rainette/releases?access_token=xxxx)

et on récupère un tableau des release en JSON avec pour chaque release le contenu suivant :

    "id": 6700,
    "tag_name": "v1.5.4",
    "target_commitish": "master",
    "name": "v1.5.4",
    "body": "Archive de la version 1 de Rainette dont l'utilisation n'est plus conseillée sauf pour les sites dont la version SPIP est inférieure ou égale à 3.0.",
    "url": "[https://git.spip.net/api/v1/repos/spip-contrib-extensions/rainette/releases/6700](https://git.spip.net/api/v1/repos/spip-contrib-extensions/rainette/releases/6700)",
    "html_url": "[https://git.spip.net/spip-contrib-extensions/rainette/releases/tag/v1.5.4](https://git.spip.net/spip-contrib-extensions/rainette/releases/tag/v1.5.4)",
    "tarball_url": "[https://git.spip.net/spip-contrib-extensions/rainette/archive/v1.5.4.tar.gz](https://git.spip.net/spip-contrib-extensions/rainette/archive/v1.5.4.tar.gz)",
    "zipball_url": "[https://git.spip.net/spip-contrib-extensions/rainette/archive/v1.5.4.zip](https://git.spip.net/spip-contrib-extensions/rainette/archive/v1.5.4.zip)",
    "draft": false,
    "prerelease": false,
    "created_at": "2020-02-06T11:10:17+01:00",
    "published_at": "2020-02-06T11:10:17+01:00",
    "author": {
      "id": 167,
      "login": "Eric",
      "full_name": "Eric Lupinacci",
      "email": "xxx",
      "avatar_url": "xxx",
      "language": "fr-FR",
      "is_admin": true,
      "last_login": "2020-12-27T09:35:43+01:00",
      "created": "2017-05-26T10:41:58+02:00",
      "username": "Eric"
    },
    "assets": []

On voit que body contient le texte saisi. On a également le tag associé et le titre et pleins d’infos sur l’état, la date de création…
Tout ce qu’il faut pour améliorer les changelogs de commits.
Je trouve cela vraiment pas mal.

On a d’ailleurs l’url des zips ce qui permettrait même de ne plus les construire non ?

6

Hello :blush:
Je comprends l'intérêt de ne faire que la distribution des numéros les plus grand et je trouve ça très bien aussi !
Maintenant, à voir si cela ne posera pas de problème avec les anciennes versions de spip, exemple imaginons que nous sortions spip 3.3 demain (je rêve) et qu'un plug à un up de "x" car cette version ne fonctionne "qu'avec" spip 3.3, il sera toujours possible de faire la distribution du plug avec "deux" versions (une pour spip 3.3 et une autre pour spip 3.2) ?

Franck

-----Message d'origine-----

7

Je suis toujours embêté par notre méthode de génération des zips basés sur les composants x et y d'une version x.y.z.

Avant de réfléchir à quoi faire pour que ce soit mieux, la question à préciser d'abord c'est : c'est quoi vraiment le problème ?

Pour la génération des zips précisément, ça ne se base sur sur "x" et "y" particulièrement, ça se base sur : dès qu'il y a un tag. Un nouveau tag = un zip, non ?

On se retrouve avec des versions 3.11.1 et 3.12.1 par exemple visibles sur Plugins SPIP, accessibles indépendamment alors que dans ce cas, 3.12.1 est à utiliser préférentiellement.

Bé oui, toutes les versions considérées comme "à rendre publique" sont là, et c'est la plus récente en premier, donc je ne vois toujours pas où est le problème. 3.12.1 est bien affiché prioritairement à 3.11.X, donc c'est bien ça qu'on voit en premier. Et il n'y a pas de raison à ce que les versions d'avant disparaisse, peut-être qu'un bug existe en 3.12.1 et qu'il FAUT pouvoir revenir (y compris ceux qui ne sont pas en git !) à la version précédente. Qu'après au niveau ergonomie c'est à nous d'afficher de la manière qu'on veut, pas forcément tout au même niveau (la version la plus haute de chaque Y en plus gros, etc), ça c'est un autre problème : ça n'empêche en rien que tout ce qui a un tag est considéré comme "pertinent à rendre public", donc avec un ZIP en rapport.

On en vient à éviter de faire un y+1 pour ne pas avoir ce type de désagrément.

Qui fait ça ? Pourquoi ? Je n'ai jamais eu l'idée de faire ça, et je ne saisis absolument pas l'intérêt.

Et plus on va avancer, plus cela sera pénible.

Vraiment je n'arrive pour le moment pas à comprendre ce qui est spécialement pénible, ni pour qui.

8

Re,

Avant de réfléchir à quoi faire pour que ce soit mieux, la question à préciser d’abord c’est : c’est quoi vraiment le problème ?

Relis mieux, tu commences bien l’année…

Pour la génération des zips précisément, ça ne se base sur sur « x » et « y » particulièrement, ça se base sur : dès qu’il y a un tag. Un nouveau tag = un zip, non ?

Non. On ne zippe pas les n tags ayant les mêmes x et y.
Par contre, on génère les tags x.y et x.y+1.
Tu peux le voir sur Rainette par exemple, on a la 3.11.2 et la 3.12.1 mais pas la 3.11.1.
C’est déjà bien mais la 3.11 et 3.12 ne sont pas incompatibles et la 12 est une amélioration de la 11.
Quand on voit les deux laquelle prendre ?
Et dans ce cas pourquoi ne pas voir tous les tags dans ce cas ?

Bé oui, toutes les versions considérées comme « à rendre publique » sont là, et c’est la plus récente en premier, donc je ne vois toujours pas où est le problème. 3.12.1 est bien affiché prioritairement à 3.11.X, donc c’est bien ça qu’on voit en premier. Et il n’y a pas de raison à ce que les versions d’avant disparaisse, peut-être qu’un bug existe en 3.12.1 et qu’il FAUT pouvoir revenir (y compris ceux qui ne sont pas en git !) à la version précédente. Qu’après au niveau ergonomie c’est à nous d’afficher de la manière qu’on veut, pas forcément tout au même niveau (la version la plus haute de chaque Y en plus gros, etc), ça c’est un autre problème : ça n’empêche en rien que tout ce qui a un tag est considéré comme « pertinent à rendre public », donc avec un ZIP en rapport.

C’est un point de vue que je ne partage pas d’autant que si on devait revenir en arrière je ne vois pas pourquoi on ne verrait pas dans ce cas tous les tags z compris ?

Donc ce n’est pas une justification valable.

Qui fait ça ? Pourquoi ? Je n’ai jamais eu l’idée de faire ça, et je ne saisis absolument pas l’intérêt.

pfff… je fatigue.

Vraiment je n’arrive pour le moment pas à comprendre ce qui est spécialement pénible, ni pour qui.

Là je suis vraiment fatigué.

9

Je suis toujours embêté par notre méthode de génération des zips basés sur les composants x et y d'une version x.y.z.

Avant de réfléchir à quoi faire pour que ce soit mieux, la question à préciser d'abord c'est : c'est quoi vraiment le problème ?

Pour la génération des zips précisément, ça ne se base sur sur "x" et "y" particulièrement, ça se base sur : dès qu'il y a un tag. Un nouveau tag = un zip, non ?

il faut distinguer conceptuellement
- le zippage par tags (qui est fait automatiquement par gitea)
- le listage dans plugins/contrib
- la distribution via svp

la question étant de savoir si les 3 doivents ou pas être strictement les mêmes

On se retrouve avec des versions 3.11.1 et 3.12.1 par exemple visibles sur Plugins SPIP, accessibles indépendamment alors que dans ce cas, 3.12.1 est à utiliser préférentiellement.

peut-être qu'un bug existe en 3.12.1 et qu'il FAUT pouvoir revenir (y compris ceux qui ne sont pas en git !) à la version précédente.

mouais, alors dans ce genre de cas, la distribution via gitea suffit non ? pas besoin de charger cela en plus dans svp ?

Qu'après au niveau ergonomie c'est à nous d'afficher de la manière qu'on veut, pas forcément tout au même niveau (la version la plus haute de chaque Y en plus gros, etc), ça c'est un autre problème : ça n'empêche en rien que tout ce qui a un tag est considéré comme "pertinent à rendre public", donc avec un ZIP en rapport.

10

Bah si on va par là, moi je suis fatigué de rien comprendre à un problème qui n'est pas vraiment expliqué, ou pas assez bien expliqué.

Déso mais je comprends RÉELLEMENT PAS où est le problème. Peut-être je suis débile.

Ça affiche TOUS les "y" existants, dans leur dernière version "z" (ou dit à l'envers : le dernier "z" de chaque "y" existant). Sachant qu'un "y" c'est un changement important (normalement pas cassant, mais important), pas juste une correction de bug. Donc totalement légitime de voir chaque "y" ayant existé. Entre deux "y" il peut y avoir de grosses différences, de gros ajouts.

Qu'on décide ergonomiquement d'afficher la plus récente en plus énorme, et les autres en pitit pitit, c'est une chose, un guide pour le choix. Mais c'est juste de l'ergonomie (et ce n'est pas fait actuellement). Ça ne change rien qu'on ne supprime jamais une release (et le fait de décider de faire un tag = c'est qu'on veut publier), et que ça doit rester dispo à l'avenir.

Et c'est bien ça la norme dans tous les projets PHP bien carrés, sur composer, sur github, et donc sur packagist ensuite.

https://github.com/symfony/routing
=> 488 releases ! : 100% des tags et donc y compris tous les Z !

https://packagist.org/packages/symfony/routing
=> central = dernière version puis sur le côté droit un bloc avec toutes les précédentes versions : 100% des tags aussi (normal vu que ça vient de la même source que le github à priori)

J'irais même jusqu'à dire que chez nous on n'en affiche *pas assez* même ! Et que donc oui il faudrait tous les Z justement, comme les autres projets Composer. Mais ensuite c'est à l'ergonomie d'être adaptée et bien pensée pour mettre en avant ce qui est le plus pertinent en gros en premier, et en plus petit/replié ce qui est passé.

Et que donc pour moi le problème est inverse :
1) Il manque les Z, il devrait tout y avoir, pas moins.
2) C'est l'ergonomie (donc juste du squelette SPIP, pas l'empaqueteur) qui devrait être revue pour vraiment fortement en avant les derniers X/Y les plus pertinents et en petit voire replié les archives du passé, une vraie hiérarchisation pas tout au même niveau.

11

Hello,

Là je suis vraiment fatigué.
Bah si on va par là, moi je suis fatigué de rien comprendre à un problème qui n’est pas vraiment expliqué, ou pas assez bien expliqué.
Déso mais je comprends RÉELLEMENT PAS où est le problème. Peut-être je suis débile.

Non mais tu as très bien compris même si je ne l’ai pas exprimé clairement il est vrai.
Mais si ton expression était plus amène ça serait mieux pour tout le monde et plus serein.
Il n’y a aucune polémique dans le sujet abordé, on est pas obligé d’en créer par une expression brutale ou ironique.

Ça affiche TOUS les « y » existants, dans leur dernière version « z » (ou dit à l’envers : le dernier « z » de chaque « y » existant). Sachant qu’un « y » c’est un changement important (normalement pas cassant, mais important), pas juste une correction de bug. Donc totalement légitime de voir chaque « y » ayant existé. Entre deux « y » il peut y avoir de grosses différences, de gros ajouts.

La notion d’important pour le y est quand même floue et à l’adresse de tout un chacun.
Donc qualifier le subjectif ce n’est pas simple surtout quand on n’a aucun changelog humainement compréhensible qui va avec.

Qu’on décide ergonomiquement d’afficher la plus récente en plus énorme, et les autres en pitit pitit, c’est une chose, un guide pour le choix. Mais c’est juste de l’ergonomie (et ce n’est pas fait actuellement). Ça ne change rien qu’on ne supprime jamais une release (et le fait de décider de faire un tag = c’est qu’on veut publier), et que ça doit rester dispo à l’avenir.

Oui le problème est ergonomique au sens large.
Et oui, ça concerne plus les utilisateurs « standard » de SPIP que les dev et les intégrateurs qui sont aujourd’hui qu’on le veuille ou non ceux à qui on s’adresse le plus au détriment des autres.
Pour ces utilisateurs « standard » le fait de voir une page comme celle de Saisies sur Plugins SPIP, avec ces dizaines de versions à la suite dans lesquelles on ne distingue même plus le moment où l’on passe de la branche 3 à la branche 2, ça doit interroger.
Et pas besoin d’avoir 50 versions pour avoir ce sentiment de fouillis.

Alors je ne dis pas qu’il ne faut pas zipper les tags (c’est là où je pense que mon expression était brumeuse) et de toute façon les zips existent par défaut dans la forge, je dis qu’il n’est pas nécessaire d’embrouiller tout le monde sur des sites où l’on veut être simple pour ceux qui ne sont pas développeurs.
Après le deuxième problème ergonomique que l’on a aussi sur SVP c’est pourquoi on fait la maj ?

Et la à part lire un log de commit (pas disponible sous SVP) pas toujours très disert on a rien de très lisible.
Et savoir à quoi s’attendre, si on va devoir ajouter un nécessite (qui ne justifie pas une nouvelle branche) ou autre serait un plus.

Et c’est bien ça la norme dans tous les projets PHP bien carrés, sur composer, sur github, et donc sur packagist ensuite.

https://github.com/symfony/routing
=> 488 releases ! : 100% des tags et donc y compris tous les Z !

https://packagist.org/packages/symfony/routing
=> central = dernière version puis sur le côté droit un bloc avec toutes les précédentes versions : 100% des tags aussi (normal vu que ça vient de la même source que le github à priori)

Mais là on ne parle pas du même type de logiciel. On ne peut pas comparer le framework Symfony et SPIP en particulier pour les gens qui utilisent SPIP pour faire de la publication uniquement.

Donc non, ce n’est pas la norme sauf pour les développeurs.

J’irais même jusqu’à dire que chez nous on n’en affiche pas assez même ! Et que donc oui il faudrait tous les Z justement, comme les autres projets Composer. Mais ensuite c’est à l’ergonomie d’être adaptée et bien pensée pour mettre en avant ce qui est le plus pertinent en gros en premier, et en plus petit/replié ce qui est passé.

Et que donc pour moi le problème est inverse :

  1. Il manque les Z, il devrait tout y avoir, pas moins.
  2. C’est l’ergonomie (donc juste du squelette SPIP, pas l’empaqueteur) qui devrait être revue pour vraiment fortement en avant les derniers X/Y les plus pertinents et en petit voire replié les archives du passé, une vraie hiérarchisation pas tout au même niveau.

Qu’il manque des Z c’est vrai et c’est faux : pour la forge, le débardeur refait le travail il me semble alors que tous les zips de tous les tags sont déjà disponibles sur Gitea. Mais par contre il crée ceux qui ne sont pas sur Gitea ce qui est nécessaire.
Il filtre justement sur le z parce que l’on distribue/affiche tous les zips sortis du débardeur; on pourrait filtrer les affichages sur une liste de zips complète, oui ça serait peut-être une partie de la solution, à ceci près qu’il faudrait reprendre les affichages…

Après pour moi ça ne règle pas le problème du changelog explicite qui est parfois plus que nécessaire, en particulier pour un changement de y.

12

Pour ces utilisateurs "standard" le fait de voir une page comme celle de Saisies sur Plugins SPIP, avec ces dizaines de versions à la suite dans lesquelles on ne distingue même plus le moment où l'on passe de la branche 3 à la branche 2, ça doit interroger.

On pourrait n'afficher par défaut que la dernière version de la branche x, les autres étant masquées par défaut dans un bloc déroulant.
Ce serait beaucoup plus lisible, tout en donnant accès a tous les zips pour qui en aurait besoin.

Après le deuxième problème ergonomique que l'on a aussi sur SVP c'est pourquoi on fait la maj ?
Et la à part lire un log de commit (pas disponible sous SVP) pas toujours très disert on a rien de très lisible.
Et savoir à quoi s'attendre, si on va devoir ajouter un nécessite (qui ne justifie pas une nouvelle branche) ou autre serait un plus.

Ça, c'est un vrai et vieux problème.
On pourrait utiliser le log de commit du tag et l'afficher dans SVP ?

Sur ta proposition d'utiliser les versions de Gitea, si c'est une fonctionnalité spécifique à Gitea je ne suis pas chaud : on ne pourrait pas la reproduire si on devait changer de forge, ou bien sur un miroir.

13

Re,

On pourrait n’afficher par défaut que la dernière version de la branche
x, les autres étant masquées par défaut dans un bloc déroulant.
Ce serait beaucoup plus lisible, tout en donnant accès a tous les zips
pour qui en aurait besoin.

Oui, tout à fait.
Je dirais même que le bloc actuel de Plugins SPIP avec tous les détails ne devrait être affiché que pour la dernière version d’une branche.
Les autres versions avec le même x et des y.z différents devraient être listées simplement avec un lien de téléchargement et une façon simple de faire apparaître le changelog entre les versions.

Après le deuxième problème ergonomique que l’on a aussi sur SVP c’est
pourquoi on fait la maj ?
Ça, c’est un vrai et vieux problème.
On pourrait utiliser le log de commit du tag et l’afficher dans SVP ?

Le log de commit est un pis-aller mais il ne correspond pas pour moi à un changelog compréhensible pour tous.

Sur ta proposition d’utiliser les versions de Gitea, si c’est une
fonctionnalité spécifique à Gitea je ne suis pas chaud : on ne pourrait
pas la reproduire si on devait changer de forge, ou bien sur un miroir.

A priori Github a aussi cette notion de release et Gitlab un notion d’étiquette.

Je n’ai pas vérifié si cela coïncide exactement.
Après, il y a une façon simple de faire un changelog c’est un fichier… changelog (d’ailleurs y a une option dans Gitlab pour en ajouter un au repo).
Il suffirait qu’il ait une structure standard pour servir partout où on en aurait besoin comme le paquet.xml d’ailleurs.

Sans être obligatoire néanmoins.

14

Re,

Le lun. 4 janv. 2021 à 13:16, nicod_ <nicod@lerebooteux.fr <mailto:nicod@lerebooteux.fr>> a écrit :

    On pourrait utiliser le log de commit du tag et l'afficher dans SVP ?

Le log de commit est un pis-aller mais il ne correspond pas pour moi à un changelog compréhensible pour tous.

je pense que nicod parlais du log de commit de TAG différent du log standard
il est possible en effet d'associer des messages à un tag, même si en pratique nous ne le faisons pas souvent (mais on devrait, de même qu'on devrait signer nos tags avec PGP).

Après, il y a une façon simple de faire un changelog c'est un fichier... changelog (d'ailleurs y a une option dans Gitlab pour en ajouter un au repo).
Il suffirait qu'il ait une structure standard pour servir partout où on en aurait besoin comme le paquet.xml d'ailleurs.
Sans être obligatoire néanmoins.

peut être une solution plus simple en effet (mais faut voir si il existe un standard)

15

Bonsoir tout le monde,

> Re,
>

> On pourrait utiliser le log de commit du tag et l'afficher dans SVP ?
>
>
> Le log de commit est un pis-aller mais il ne correspond pas pour moi à
> un changelog compréhensible pour tous.

je pense que nicod parlais du log de commit de TAG différent du log standard
il est possible en effet d'associer des messages à un tag, même si en
pratique nous ne le faisons pas souvent (mais on devrait, de même qu'on
devrait signer nos tags avec PGP).

Ah les étiquettes annotées
https://git-scm.com/book/fr/v2/Les-bases-de-Git-Étiquetage
Si on veut que ce soit la règle on peut ne prendre en compte que ce
type de tags…

> Après, il y a une façon simple de faire un changelog c'est un fichier...
> changelog (d'ailleurs y a une option dans Gitlab pour en ajouter un au
> repo).
> Il suffirait qu'il ait une structure standard pour servir partout où on
> en aurait besoin comme le paquet.xml d'ailleurs.
> Sans être obligatoire néanmoins.
>
peut être une solution plus simple en effet (mais faut voir si il existe
un standard)

Il n'y a pas de standard établi (genre IETF/W3C/etc.) mais _presque_
un standard de faits (ou bonnes règles) dont on a un bon récapitulatif
sur Tenez un Changelog qui est sourcé ouvertement
sur GitHub - olivierlacan/keep-a-changelog: If you build software, keep a changelog.
Il y a une petite variation sur
A Beginner’s Guide to Git — What is a Changelog and How to Generate it
mais on retrouve bien les mêmes points principaux…

Si l'usage des étiquettes annotées est systématique (pour documenter
chaque nouvelle version livrée) on peut programmaticalement générer le
fichier pour toutes les versions. Voir par exemple le billet suivant
http://lkdjiin.github.io/blog/2013/09/04/generer-un-fichier-changelog-avec-git/

16

Bonsoir la liste,

Re,

[…]

Sur ta proposition d'utiliser les versions de Gitea, si c'est une
fonctionnalité spécifique à Gitea je ne suis pas chaud : on ne pourrait
pas la reproduire si on devait changer de forge, ou bien sur un miroir.

A priori Github a aussi cette notion de release et Gitlab un notion d'étiquette.
Je n'ai pas vérifié si cela coïncide exactement.

Attention, il y bien les étiquettes (tags) qui sont une fonctionnalité
de Git qu'on retrouve dans beaucoup de systèmes de gestions de
versions.
Il y a aussi les publications/versions (releases) qui s'appuient sur
les précédents en y ajoutant la génération des artéfacts et une note
de publication… On retrouve cela dans les principales forges basées
sur Git
- Releases | GitLab
- Managing releases in a repository - GitHub Docs
- Gitea reprend des fonctionnalité de Github que ne reprend pas Gogs,
et les versions sont maintenant automatiquement générée
https://christine.website/blog/gitea-release-tool-2020-05-31

Pour passer d'une forge à une autre, il y a un travail d'adaptation à prévoir…

[…]

17

Hello

La notion de release n'est pas un concept git. Cela est propre aux
forge. À ma connaissance toute les forges proposent cette fonctionnalité
(gitea, gogs, gitlab, github, ...)

La différence réside dans le principe de diffusion du code. Un tag est
un marqueur dans le code tandis qu'une release est une version prête à
l'emploi.
Les release peuvent être de simple zip mais on peut aller plus loin. Par
exemple chez alternc on exploite les releases pour fournir directement
des paquets debian.
Pour les projets en go, comme gitea, sont proposés les executables pour
chaque plateforme (linux, mac, bsd, ....)

Dans notre cas, on a juste besoin de zip et cela ne change pas grand
chose à ce que proposait trac avec les urls de téléchargement.

Une release est reproductible, c'est toujours une même recette appliquée
sur un tag.

Km

18

Hello,

Si je résume un peu ce qui a été dit.

  1. Le problème ne concerne pas les tags ni la génération systématique des zips par le débardeur. On pourrait même étendre à l’ensemble des tags si on voulait… Maintenant, ne pourrait-on pas éviter de regénérer les zips existant sur Gitea ?

  2. Il faut adapter les affichages sur Plugins SPIP (et bientôt Contrib) pour mettre en avant les dernières versions de chaque branche et en second rideau les autres versions (ergo à définir).

  3. Un changelog serait utile à la fois dans les affichages Plugins SPIP et dans SVP afin de décider de la mise à jour en connaissance de cause.

  4. Le plus simple et portable serait de créer un fichier CHANGELOG.txt ou .md à la racine des plugins qui pourrait être utilisé par Plugins SPIP ou SVP sous un forme à définir.

  5. le format du changelog pourrait s’inspirer de : https://keepachangelog.com/fr/1.0.0/

  6. l’existence du changelog est facultative.

Ca peut faire une roadmap sympa il me semble non ?

19

j'agrèe sur tout les point, sauf sur 1 où je ne comprend pas "Maintenant, ne pourrait-on pas éviter de regénérer les zips existant sur Gitea". Je pensais, naivement qu'on les recuperait tel quel et qu'on se contentait de les lire...

Je me demande aussi s'il ne faudrait pas proposer à terme 2 flux, l'un ne contenant que le dernier x et y, l'autre contenant tout, comme actuellement. parce que deja que le flux actuel fait 10 Mo, si on augmente encore le nombre de tags, ca va faire bcp.

20

1) Le problème ne concerne pas les tags ni la génération systématique des zips par le débardeur. On pourrait même étendre à l'ensemble des tags si on voulait... Maintenant, ne pourrait-on pas éviter de regénérer les zips existant sur Gitea ?

C'est pas déjà le cas, genre si le débardeur voit que ça existe sur gitea, il le récupère tel quel ?

2) Il faut adapter les affichages sur Plugins SPIP (et bientôt Contrib) pour mettre en avant les dernières versions de chaque branche et en second rideau les autres versions (ergo à définir).

+1

3) Un changelog serait utile à la fois dans les affichages Plugins SPIP et dans SVP afin de décider de la mise à jour en connaissance de cause.
4) Le plus simple et portable serait de créer un fichier CHANGELOG.txt ou .md à la racine des plugins qui pourrait être utilisé par Plugins SPIP ou SVP sous un forme à définir.
5) le format du changelog pourrait s'inspirer de : Tenez un Changelog
6) l'existence du changelog est facultative.

+1, c'est un autre sujet qui là nécessite des évolutions à l'infrastructure (pas juste l'affichage final), mais clairement oui : il y a d'ailleurs un ticket déjà dessus depuis 5 ans…
https://core.spip.net/issues/3509

Ca peut faire une roadmap sympa il me semble non ?

Sur les tickets, il y a des choses qu'on a liées au 3509, notamment

- https://core.spip.net/issues/4256 qui parle de distinguer (donc étiqueter en amont, donc infrastructure aussi) spécifiquement les màj contenant de la sécurité : ce n'est pas pareil que Z qui change (ça peut être sécu ou juste petit bug, on sait pas), et ce n'est pas pareil qu'un changelog complet, qui est le détail humain, mais qui ne permet pas de le savoir informatiquement, et donc de le mettre en avant (que ce soit sur les sites de la galaxie ou dans les SPIP des gens)

- https://core.spip.net/issues/3017 dont la conséquence est que SVP devrait être amélioré pour connaitre plus qu'une unique mise à jour existante : en effet à un instant T, un plugin peut avoir une version majeure sortie X+N *et* une version Y+N ou même juste Z+N, et l'utilisateur ne veut PAS forcément changer de X, mais bien changer que Y voire même ne changer que Z pour être sûr de ne rien casser et avoir juste les corrections. Au niveau ergonomique, le travail est en gros fini, mais par contre, la conception de SVP ne le permet pas, donc pas possible de générer plusieurs boutons de mises à jour différentes à la fois. (Exemple de Sézi dans la maquette, qui a 4 mises à jour possible à la fois)

Ce dernier point est le plus compliqué il me semble, car SVP c'est compliqué et qu'il y a eu un gros angle mort de conception sur ce point on dirait. Cependant j'ai l'impression que pour les utilisateurs finaux (qui ne suivent pas le code), c'est encore bien plus important qu'avoir le changelog complet : les gens devraient absolument pouvoir faire des mises à jour mineures, sans qu'on leur montre uniquement la majeure, et illes sont capables de choisir l'option la moins dangereuse pour elleux même sans changelog complet avec les phrases claires et simples (on comprend la différence entre "màj corrective/fonctionnelle/majeure" et donc la dangerosité ou pas à changer sans tout péter).

Mais faisons déjà les choses "simples", sur lesquelles on a la main plus vite.