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 …
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 suivantesprécédentes …
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).
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 …
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 ?
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.
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
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.
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.
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.
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.
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.
!