Fluidifier la création de releases

Équipes maintenance
#5

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

1 « J'aime »
#6

Un message a été scindé en un nouveau sujet : labels de groupe pour spip/*

#7

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 …

#8

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 :

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 » :

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

Pas super claro.

#9

Nous sommes en phase là-dessus :slight_smile:

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.
#10

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 :slight_smile:

#11

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

#12

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.

#13

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

#14

Je sais bien que je suis un peu vieux et benêt mais quand même :wink: !
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.

#15

+1, ça oblige à jongler un peu… :face_with_head_bandage:

Mébon, si ça facilite le travail de maintenance pour moi ce n’est pas un argument (je dis bien : pour moi).

#16

Ouep et ça oblige à revenir au fait de toujours créer une branche qui suit spip même si le plugin n’a pas été modifié fonctionnellement ou par corrections.
Donc c’est pas bon, ok.

Par contre, sur SPIP.net on pourrait imaginer lors d’une release spip de préciser les versions des plugins dist embarqués car le spip nu n’est pas ce qui est distribué aujourd’hui. Un tableau récapitulatif.

#17

Je vais peut-être dire une connerie, mais je crois bien que c’est ce que fait le fichier composer.json cf composer.json · master · spip / spip · GitLab en master et le fichier plugins-dist.json · 4.2 · spip / spip · GitLab en 4.2.

#18

PS : je commence à me dire qu’on devrait scinder ce fil à partir du message de tonton Fluidifier la création de releases - #10 par eric_tonton car on semble s’écarter du sujet initial non ?

#19

Du coté pratique, je trouve que d’avoir une lisibilité de la compatibilité d’un plugin-dist avec son nom de branche serait très pratique. Sinon, quand on veut récupérer la branche corresponde à une version de SPIP, il faut faire le tour des différents fichiers : paquet.xml.

#20

Perso, je trouve qu’on est en plein dedans.

Mais c’est vrai qu’au départ, on parlait des simplifications qu’on pourrait mettre en place pour la création de releases en général : gestion des dépendances, outils, CI/CD … Je me plante peut-être, mais de cet ensemble, une question fondamentale, c’est la gestion des dépendances … qui n’est pas « maîtrisée » par toute l’équipe…

Il faut bien comprendre qu’à partir de SPIP5, c’est par composer que ça passe :

  • C’est avec ça qu’on produit les zips de SPIP5.
  • Avant (et donc, encore aujourd"hui pour les 4.x), on « bricole » un plugins-dist.json et il y a toujours la gestion des plugins de SPIP (+SVP) qui check l’attribut compatibilite, les necessite, etc. du paquet.xml.
  • La compat spip/plugins-dist via composer pourrait être améliorée, mais actuellement, on pourrait très bien se passer de la vérification de la compat des plugins-dist …
  • On a de vieux topics sur le fait de rendre facultatif les attributs version/etat/compatibilite. On pourrait remettre ça sur le tapis. On les enlèverait des plugins-dist mais ça marcherait pour les contribs … par exemple.

Je dis depuis un certain temps qu’on peut assez facilement passer à composer pour les versions d’avant la 5 pour les plugins-dist. Uiliser une seule technique pour toutes les versions maintenues, ce serait déjà un plus … on s’épargnerait quelques commits lors des releases mensuelles.

Et donc, au final, qu’un plugin-dist suive le cycle de vie de SPIP ou pas peut se décider au cas par cas. le squelettes-dist pourrait être sur les mêmes versions X.Y que SPIP par exemple, l’écran de sécu à son propre cycle depuis longtemps, … certains plugins-dist n’ont pas la moindre dépendance à l’API de SPIP, et c’est beaucoup plus logique qu’ils aient leur propre rythme de version.

Bref, s’il le faut, diversifions les topics, mais de toute manière, il y a une grosse imbrication des enjeux et du code qu’il faut démêler comme un ensemble.

1 « J'aime »
#21

Je reviens une fois de plus sur les milestones/branches/versionning des plugins-dsit.

Trouver une solution qui conviendra à tout le monde sera difficile et va de prendre du temps. J’essaierai dans les jours prochains de montrer des cas concrets, moins théoriques.

En attendant, je propose un truc qui devrait être assez consensuel :

Faire sur les plugins-dist comme cela a été fait sur spip/spip : supprimer les milestones qui ne servent pas ou plus :

Clôture de :

  • « < spip-3.2 »
  • « spip-4.0 »
  • « spip-3.2 »

Suppression de :

  • « 100 rejeté »
  • « 99 plus tard »
  • « 90 a confirmer »
  • « 00 urgent »
  • « spip-4.6 »
  • « spip-4.5 »
#22

gogogo !

1 « J'aime »
#23

Done.

#24

Voici La liste des milestones de spip/*. C’est bigarré.

Qu’y a-t-il comme projets git dans spip/* ?

Il y a, en gros, 4 sortes de projets dans ce groupe :

  1. spip/spip
  2. les « vieux » plugins-dist. C’est-à-dire les plugins SPIP qui ne sont plus distribués dans les versions maintenues. Ex: jquery_ui, msie_compat.
  3. les plugins-dist. Ex: spip/medias, spip/images, spip/dist.
  4. des nouveaux composants qui ne sont pas des plugins SPIP. Ex: spip/logger, un package composer, spip/composer-installer, le plugin composer pour SPIP.

spip/spip

  • Ses branches et ses milestones sont « synchronisés ».
  • On a une roadmap qui se précise et qui pilote les releases mensuelles, les sorties de versions mineures et majeures.
  • Dans la branche master, correspondant actuellement au développement de la 5.0, on se sert de composer pour installer des dépendances tierces, des packages spip, des plugins-dist.
  • le zip de release est produit par un des outils conçu et maintenu par @marcimat et s’appuie sur la commande composer archive
  • ce dernier est « déployé » sur le site files.spip.net

les « vieux » plugins-dist

  • ne sont pas composerisés.
  • ne sont plus maintenus « en parallèle » de spip, puisque plus distribués avec.
  • ne sont peut-être même plus maintenus du tout, ni par l’ex-core-team, ni par l’équipe de maintenance
  • les zips sont produits par le débardeur, déployés sur files.spip.net pour être référencés sur l’actuel plugins.spip.net afin d’être installable par SVP.

les plugins-dist

  • ils ont été composerisés dans leurs branches liées à SPIP5
  • ils suivent les sorties de spip/spip
  • ils sont « faciles » à identifier : on les retrouvent à la fois dans le fichier composer.json dans la branche 5.0 de spip/spip et dans le fichier plugins-dist.json des branches 4.x
  • ils ont leurs propres versions au niveau branches git, mais des milestones faisant référence au cycle de vie de spip/spip
  • les zips sont produits par le débardeur, déployés sur files.spip.net pour être référencés sur l’actuel plugins.spip.net afin d’être installables par SVP (sauf que peut-être pas…, je ne sais pas). Mais, ils sont aussi référencés sur le dépôt composer de SPIP, automatiquement via des webhooks, pour être installables par composer qui s’appuie désormais sur les zip produit par GitLab lui-même.

les nouveaux composants

  • ils sont composerisés depuis leur création
  • ils sont conçus pour être totalement indépendant du code de spip/spip
  • ce ne sont pas des plugins SPIP, ils sont destinés à être installés dans vendor et non dans plugins-dist ou plugins
  • ils ont leurs propres cycles de vie, tant au niveau branches que milestones
  • ils sont référencés sur le dépôt composer de SPIP, automatiquement via des webhooks, pour être installables par composer

(installable = ajouté et/ou mis à jour, dans une release ou individuellement)

Et donc ?

Vous pouvez constater que chaque sorte de projet correspond à une organisation différente de leur développement et de leur maintenance, voire, concerne des personnes « différentes », si on pousse le concept un peu plus loin.
Avec le cas plus ou moins compliqué des plugins-dist.

Selon moi, même si un autre choix a été fait dans le passé pour ce qui les concerne, les plugins-dist (pas les « vieux ») restent liés aux sorties de SPIP et pourraient très bien partager le même cycle de vie. On a de la chance, dans une certaine mesure, aucun plugin-dist actuel n’ pour version un numéro supérieur à 4.4 (medias).
Mais ce n’est pas obligatoire, les outils de @marcimat gère les changements de branche et les créations de tags, avec un peu d’huile de coude parfois (la fameuse « fluidification » :stuck_out_tongue: )

Concrètement

Je pense qu’on peut faire des choses parmis les suivantes :

  1. déplacer les « vieux » plugins dans spip-contrib-extensions pour, espérons-le, qu’ils soient plus accessibles, ou au moins plus visibles par d’autres contributeurices que les historiques de l’ex-core-team ou ceux de l’actuelle team @maintenance pour une éventuelle reprise d’activité
  2. passer au même cycle de vie (labels+milestones+branches) pour spip/spip et les plugins-dist (et ainsi d’avoir des milestones de groupes, comme pour les labels) pour spip/*
  3. créer un groupe distinct pour les nouveaux composants

OU

  1. déplacer les « vieux » plugins dans spip-contrib-extensions pour, espérons-le, qu’ils soient plus accessibles, ou au moins plus visibles par d’autres contributeurices que les historiques de l’ex-core-team ou ceux de l’actuelle team @maintenance pour une éventuelle reprise d’activité
  2. conserver le status-quo pour les plugins-dist et continuer d’utiliser les outils de @marcimat tels quels
  3. créer un groupe distinct pour les nouveaux composants

OU

seulement 1.
seulement 3.

OU

rien :slight_smile: