Release, Git, Composer

# 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