# 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) ?
