Re: Gitea et le débardeur

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 ?


++
Eric


Le mar. 5 janv. 2021 à 10:20, cam.lafit <[email protected]> a écrit :

> 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
>
>
> Le 05/01/2021 à 02:49, Gildas Cotomale a écrit :
> > Bonsoir la liste,
> >
> > Le lun. 4 janv. 2021 à 14:02, Eric Lupinacci a écrit :
> >>
> >> Re,
> >>
> >> Le lun. 4 janv. 2021 à 13:16, nicod_ <[email protected]> a écrit :
> > […]
> >>>
> >>> 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
> > - https://docs.gitlab.com/ee/user/project/releases/
> > -
> https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/managing-releases-in-a-repository
> > - 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…
> >
> >
> > […]
> > _______________________________________________
> > 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