Re: Release, Git, Composer

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