Salut @eric_tonton,
Merci 
Ce qu’il faut retenir pour l’instant, c’est que nous nous sommes limités à SPIP et aux plugins-dist+squelettes-dist+ecran de sécurité. L’objectif étant, pour cette étape, d’améliorer et de faciliter la fabrication des releases de SPIP5, et dans la mesure du possible pour le développement en local, mais dans la limite de SPIP et ses plugins-dist.
Je suis heureux de voir que ça donne envie, mais en l’état actuel, ce que nous avons mis en place ne nous permet pas encore d’utiliser composer pour le développement et la distribution des plugins « non-dist » et nous ne pouvons pas dire quand et comment ce sera possible.
Bref, on y travaille et nous allons créer de nouveaux sujets pour parler de tout cela dans les semaines à venir.

Tout de même, pour te répondre, je pense qu’il n’y a pas besoin de définir une stratégie commune pour « composeriser » des plugins dans le futur, si ce n’est d’adopter le fonctionnement de base de composer
:
- Les branches git représentent soit une branche de maintenance soit un développement en cours. On différencie les branches de maintenance des autres, notamment parce qu’elles représentent, via un nom de type
X.Y
, l’état le plus stable d’une ancienne « famille de versions ». Il est souhaitable, mais pas nécessaire, de supprimer les branches de développement quand elles sont mergées, et de ne supprimer les branches de maintenance que lorsqu’on arrête, justement, de maintenir une X.Y
.
- Une de ces branches peut représenter l’état le plus stable du développement de la « famille de versions » la plus récente d’un plugin. Bien souvent c’est la branche par défaut du dépôt git et effectivement, sur gitea, c’est
master
qui est proposé.
- Les tags qui respectent semver représentent des versions. (tout autres tags n’étant pas pris en compte par composer et les systèmes de distribution de packages associés). On peut donc les faire dans
master
ou dans une branche de maintenance si besoin.
Certains appellent ça le Trunk Based Development, je crois. Pour nous, le « trunk » étant la branche master
, le tout est combiné avec quelques règles de semantic versionning.
En résumé, ce que tu décris pour tes plugins me semble assez proches de ça, les plugins-dist, quant à eux, suivant déjà globalement ce principe. À la vérité, composer ne fait que s’appuyer sur des « bonnes pratiques » déjà répandues dans l’écosystème PHP, bien avant git (cf le « standard layout » de subversion) et que nous avions déjà adopté pour spip.