Fluidifier la création de releases

[JamesRezo]

Je note ici à partir des remarques de @marcimat : SPIP 5.0: lifecycle (ou le nombre et la durée de vie des versions mineures) - #2 par marcimat

En résumé, ça traite de :

• s’occuper des branches de spip/spip, changelog, reports & adaptations, et faire les releases
• gèrer le cycle de vie des plugins-dist

Enfin, en sous-entendu, les outils qui servent à créer les releases et sur quels mécanismes ils s’appuient.

Selon moi, fluidifier revient à mettre en place des automatismes et à systématiser certaines pratiques entre spip/spip et les plugins-dist. Mais le sujet reste ouvert …

EDIT: J’ai oublié de mentionner le billet de blog qui parle du sujet.
EDIT2: d’autres diront:

moins de choses à faire pour une release (plus d’automatismes & de vérifications des TU par exemple)

Et alors, on re-parlera de CI…

[JamesRezo]

Un tour du coté du plugin-dist compresseur.

Voici, à l’intant t, la situation du plugin compresseur.

Je l’ai pris un peu au hasard pour illustrer ce qu’on pourrait faire sur le cycle de vie des plugins-dist.

Milestones actuelles

Elles sont basées sur les versions de SPIP, et non ses versions à lui.

Branches actuelles

Il y a un mix entre versions du plugin (les plus récentes) et des spip-x.y refletant la version cible de SPIP.

Issues actuelles

2 labels importants : bug et amélioration, comme dans SPIP. liées au dépôt git spip/compresseur

Qu’est qu’on peut faire avec GitLab ?

• On peut, ou non, mettre en commun les labels dans l’orga (ou groupe) spip : les mêmes labels pour spip/spip, les plugins-dist et tous projets git du groupe spip
• On peut supprimer, ou non, certaines branches non maintenues, comme expliqué pour spip/spip
• On peut garder les branches basées sur la version mineure du plugin OU BIEN les renommer en fonction de la version cible de SPIP.
• On peut clore certaines milestones, en supprimer d’autres et renommer les « plus récentes » de 2 manières : selon la version du plugin ou selon la version cible de SPIP.

Idéalement, et pour des raisons assez pratiques, ils seraient mieux d’avoir une cohérence entre les branches et les milestones et par conséquent la version du plugin :

• Milestone 5.0, branche 5.0/master/main/… version du plugin dans paquet.xml = 5.0.0-dev, compat SPIP « 5.x-dev », idem dans composer.json
• Milestone 2.2, branche 2.2/master/main/… version du plugin dans paquet.xml = 2.2.0-dev, , compat SPIP « 5.x-dev », idem dans composer.json

Et on adapterait pour les versions suivantes précédentes …

[b_b]

@JamesRezo

On peut, ou non, mettre en commun les labels dans l’orga (ou groupe) spip : les mêmes labels pour spip/spip, les plugins-dist et tous projets git du groupe spip

+1

@JamesRezo

On peut supprimer, ou non, certaines branches non maintenues, comme expliqué pour spip/spip

+1 aussi

@JamesRezo

On peut garder les branches basées sur la version mineure du plugin OU BIEN les renommer en fonction de la version cible de SPIP.

Je ne suis pas certain que ça soit une bonne idée, ça réintroduirait ce dont on se serait débarrassé en supprimant les vielles branches spip-3.1, etc.

@JamesRezo

On peut clore certaines milestones, en supprimer d’autres et renommer les « plus récentes » de 2 manières : selon la version du plugin ou selon la version cible de SPIP.

Claro que si !

[nicod]

@b_b

@JamesRezo

On peut garder les branches basées sur la version mineure du plugin OU BIEN les renommer en fonction de la version cible de SPIP.

Je ne suis pas certain que ça soit une bonne idée, ça réintroduirait ce dont on se serait débarrassé en supprimant les vielles branches spip-3.1, etc.

Je ne suis pas certain de à quoi tu disais que tu n’étais pas certain : garder les branches ? ou bien les renommer ?

Sur ce sujet, je suis étonné de voir revenir la proposition de « les renommer en fonction de la version cible de SPIP » puisqu’il avait été acté, il me semble, que c’était une mauvaise pratique (à cause de semver, ou quelque chose comme ça…)
Mais je ne retrouve pas le fil en question (c’est vieux).

@JamesRezo tu peux m’éclairer ?

[JamesRezo]

@b_b

@JamesRezo

On peut, ou non, mettre en commun les labels dans l’orga (ou groupe) spip : les mêmes labels pour spip/spip, les plugins-dist et tous projets git du groupe spip

+1

Cf. à partir de là : Proposition d'un dépôt documentation - #12 par JamesRezo
Cf. ici labels de groupe pour `spip/*` pour le traitement de ce sujet spécifique

[JamesRezo]

Je ne souhaitais pas orienter la réflexion avec mon parti pris sur le sujet.
(Parce que entre les 2 propositions concernant les plugins-dist, j’ai une préférence)

Donc, pour simplifier le code des outils de releases et faciliter le suivi sur la plate-forme gitlab, j’ai identifié ces possibilités qui ont toutes deux des avantages et des inconvénients. J’ai donc parlé des 2, par transparence …

[nicod]

@JamesRezo

Je ne souhaitais pas orienter la réflexion avec mon parti pris sur le sujet.

J’imagine que c’est à moi que tu répondais ? Pas pratique ce discourse pour savoir précisément qui répond à qui.

Ce qui me trouble c’est :

@JamesRezo

On peut clore certaines milestones, en supprimer d’autres et renommer les « plus récentes » de 2 manières : selon la version du plugin ou selon la version cible de SPIP.

Si on a des n° de branches pour les plugins-dist décorrélés de la version de SPIP (c’est le cas actuellement), les milestones ne devraient pas non plus y faire référence.
Sinon le jonglage me parait un peu compliqué intellectuellement.

En fait, je n’ai pas non plus compris à quoi @b_b répondait « claro que si » :

@b_b

@JamesRezo

selon la version du plugin ou selon la version cible de SPIP.

Claro que si !

selon la version du plugin ? ou selon la version cible de SPIP ?

Pas super claro.

[JamesRezo]

@nicod

Si on a des n° de branches pour les plugins-dist décorrélés de la version de SPIP (c’est le cas actuellement), les milestones ne devraient pas non plus y faire référence.
Sinon le jonglage me parait un peu compliqué intellectuellement.

Nous sommes en phase là-dessus

J’ai l’impression que pour le moment, le consensus est le suivant :

• Les branches et les milestones de chaque plugin-dist représenteraient les versions mineures (X.Y) du plugin,
• On peut faire un peu de ménage … qui serait détaillé avant action, bien sûr,
• Pour la mise en commun de certains labels, voir l’autre sujet.

[eric_tonton (Eric Lupinacci)]

Hello,

Pour des besoins de la Plugins SPIP j’ai voulu vérifier les modifications des plugins Sites et SVP en rapport avec la version spip 4.2 et 4.3 et j’avoue que c’est un peu compliqué à s’y retrouver car il n’y a aucun rapport entre les versions.

Ne pourrait-on pas améliorer ça en faisant en sorte, si c’est encore possible de faire coincider au moins la branche de spip avec celle des plugins ? Ainsi si je cherche les tags de Sites pour la version spip 4.2, je sais que c’est forcément 4.2.x.

Je défonce peut-être une porte ouverte

[rastapopoulos]

Ah bé non à priori, ça fait plusieurs années que petit à petit on essaye de supprimer tout ça et que les plugins aient tous leur propre cycle de vie semver. Leur version doit toujours correspondre à leurs fonctionnalités, et incompatibilités

[eric_tonton (Eric Lupinacci)]

@rastapopoulos

Ah bé non à priori, ça fait plusieurs années que petit à petit on essaye de supprimer tout ça et que les plugins aient tous leur propre cycle de vie semver.

Oui mais c’est illisible car quoiqu’on en dise les plugins-dist font partie de spip et évoluent avec les branches de spip ;).
En tout cas, il faudrait trouver un moyen simple de connaitre rapidement la compatibilité spip des plugins dist.

[b_b]

À moi de défoncer une porte ouverte, l’attribut compatibilite du paquet.xml ne suffit pas ?

[eric_tonton (Eric Lupinacci)]

Je sais bien que je suis un peu vieux et benêt mais quand même !
En fait, ce qui n’est pas facile c’est que tu as des tas de branches et de tags maintenant, donc faut les passer une par une ou un par un pour savoir, en regardant dans le paquet.xml.
Je ne trouve pas ça hyper pratique.