Je suis d’accord qu’il faut remettre au carré la convention de nommage des tags 
et branches, tant sur le core que sur les plugins du core.
On peut décider d’utiliser une convention propre à partir de la prochaine 
version 3.3, ou de remettre au propre toutes les branches et tags sur toutes 
les versions 3.x (ou tout, si on est courageux), ça me va.

Par contre, avant de releaser une 3.3 beeeeta et vu qu’on a déjà bien attendu, 
je règlerai bien cette histoire de mediabox pour éviter de s’embarquer 5 ans de 
plus avec une colorbox qui n’est plus du tout à jour...

--
Cédric
Le 14 sept. 2020 à 10:51 +0200, erational <eratio...@erational.org>, a écrit :
> Bravo Marcimat !
>
> On tente de sortir cette fameuse SPIP 3.3 beeeeta ?
>
> le pad est toujours actif:
> https://semestriel.framapad.org/p/spip3.3-beta
>
> Le 14/09/2020 à 09:59, Matthieu Marcillaud a écrit :
> > # Release, Git, Composer
> >
> > ## Outils de release
> >
> > J’ai pris un peu de temps pour faire des outils de release pour nos
> > prochaines versions, et en attendant de passer un jour espérons le à
> > Composer pour de vrai...
> >
> > Ces outils sont à des emplacements temporaires (déplacés sur la zone
> > si on les utilise vraiment) (pas la peine de mettre en marque ta page :))
> >
> > - https://gitlab.com/magraine/spip-releases
> > - https://gitlab.com/magraine/spip-archives
> > - https://gitlab.com/magraine/spip-packages
> >
> > ### spip-releases
> >
> > Ce script permet de faciliter la création des tags et changelog pour
> > SPIP et ses plugins-dist, et de pusher le tout sur les différents Git
> > correspondants. Le script s’adapte et crée (à ce jour) comme c’est
> > fait actuellement (à ce jour) sur ces git (! on en discute plus bas,
> > parce que c’est pas forcément génial...) :
> >
> > - un tag spip-x.y.z pour une branche SPIP (ou spip-x.y.z-beta pour
> > master par exemple)
> > - des tags spip/x.y.z pour les plugins dist.
> >
> > - si on release depuis master, on pose des tags de version en plus sur
> > chaque plugin (v1.0.4 du plugin) éventuellement en incrémentant la
> > version selon le contexte.
> >
> > ### spip-archives
> >
> > Ce script permet de créer un zip d’une version ou branche de SPIP.
> >
> > Il intègre 2 méthodes différentes :
> >
> > - via le résultat du script checkout.php, qui est le plus proche de ce
> > qu’on avait avant, mais a aussi quelques limitations (il lit un
> > fichier .gitsvnextmodules qui n’a plus de sens). Il utilise ensuite
> > `composer archive` pour générer une archive.
> > - via le réstulat d’un `composer install` spécial, qui utilise [un
> > plugin
> > composer-installer](https://github.com/spipremix/composer-installer)
> > spécifique et un repository composer tout aussi spécial (cf:
> > spip-packages). Il y a quelques différences (notamment l’écran de
> > sécurité est forcément à jour), et quelques micros détails.
> >
> > #### spip-packages
> >
> > Ce script génère un fichier `packages.json` de type repository pour
> > Composer en déclarant quelques versions de SPIP (branches 3.1+ et
> > derniers tags) et quelques versions de plugins (branches, derniers
> > tags, et tags spip/x.y.z), et ajoute les require qui vont bien sur
> > `spip/spip` correspondant à la branche/tag, en s’appuyant sur la
> > présence des tags `spip/x.y.z` des plugins.
> >
> > C’est assez limité comme utilisation en dehors du script spip-archives.
> >
> > ## TODO Git pour Composer
> >
> > De regarder ceci m’a fait pointer du doigt différents problèmes à
> > corriger avec les repos Git de SPIP et des plugins dist
> >
> > Effectivement il est de bon ton de suivre 'semver' pour les branches
> > et tags de version afin que Composer puisse comprendre à quoi tout ça
> > correspond.
> >
> > Problèmes rencontrés :
> >
> > ### sur spip/spip
> >
> > - les branches sont nommées `spip-3.2`.
> >   - devrait être `3.2` (ou `3.2.x` — ou à la rigueur `v3.2` ou `v3.2.x`)
> > - les tags sont nommés `spip-3.2.7`,
> >   - devrait être `3.2.7` ou `v3.2.7`
> >
> > ### sur spip/{plugin} (tel que spip/mots)
> >
> > - il existe des branches `3.2`, `3.1`, `3.0`
> >   - ces branches correspondent aux versions de SPIP et pas aux
> > branches de version du plugin
> >   - devraient être renommées `spip-3.2` pour l’historique
> > éventuellement et le maintient des versions SPIP encore actives
> >   - ne devrait plus servir pour spip >= 3.3 (ou 3.4)
> > - ils ont des tags `spip/x.y.z`
> >   - admettons (pour l’historique), mais il ne faudrait pas poursuivre
> > ça dans le futur (c’est à la distribution SPIP de mettre un require
> > adapté, et au plugin de définir sa compatibilité avec SPIP).
> > - ils n’ont pas de branches pour leurs propres versions
> > - ils n’ont pas tous les tags de leurs différentes versions
> >   - ce n’est pas forcément gênant encore.
> >
> > ### gestion des versions des plugins-dist
> >
> > Avec Git et les tags, il est possible qu’un plugin-dist n’ait pas
> > bougé entre 2 versions de SPIP.
> > On peut temporairement lui ajouter les tags `spip/x.y.z` sur le même
> > commit que le tag `spip/x.y.z-1` d’avant,
> > mais il serait plus judicieux de basculer sur une déclaration de
> > contraintes / require sur Composer, et
> >  ça permettrait du coup de décorréler possiblement mieux les mises à
> > jour des plugins-dist par rapport à SPIP.
> >
> > Typiquement :
> >
> > - spip/spip (le projet) devrait require un spip/sdk ou spip/core tel
> > que '^3.2.0' ...
> > - spip/spip pourrait déclarer require : 'spip/mots': '^1' ou '^1.11'
> > - spip/mots devrait require une version de 'spip/sdk' ou 'spip/core'
> > également
> >
> > ## Actions à trancher
> >
> > Le nom des tags et branches de spip et plugins dist est à redéfinir.
> >
> > - On est d’accord ?
> > - Avant ou après la prochaine release ?
> > - Quid de .gitsvnetxmodules qui pointe sur les SVN ? On le laisse sur
> > ce nom là en changeant son contenu pour les liens git ? On le renomme
> > .spip_modules le temps d’avoir un composer.json ? On trouve une autre
> > solution pour checkout.php (et spip-cli qui utilise le même code) ?
> >
> > _______________________________________________
> > 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

Répondre à