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 :
Il y a, en gros, 4 sortes de projets dans ce groupe :
spip/spip
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.
les plugins-dist. Ex: spip/medias, spip/images, spip/dist.
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
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 » )
Concrètement
Je pense qu’on peut faire des choses parmis les suivantes :
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é
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/*
créer un groupe distinct pour les nouveaux composants
OU
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é
conserver le status-quo pour les plugins-dist et continuer d’utiliser les outils de @marcimat tels quels
créer un groupe distinct pour les nouveaux composants
Oui pour sortir les vieux plugins-dist dans extensions MAIS je ne suis plus pour quoi @cerdic avait dit un jour que cela pouvait poser problème
Pas d’opinion pour l’heure entre les 2, me manque des pro et contra. Dans les contra : on pourrait très bien imaginer que 2 branches de SPIP partagent une meme branche d’un plugin dist, histoire de ne pas complexifier outre mesure la tache du plugin-dist. Et si un plugin nécessite un correctif d’un bug sur un plugin-dist (je pense par ex à l’archiviste), on peut indiquer la dépendance à une version du plugin-dist SANS nécessiter de forcer la main sur spip lui meme
Quelle est la raison pour laquel il faudrait un groupe distinct pour les composants ? après tout meme s’ils ne dependant pas du core de SPIP techniquement, humainement ils dependent du noyau de dev. (Pas d’opinion donc en l’absence d’autre eclairage)
Je suis plutôt pour, mais je doute un peu car certains de ces plugins méritent encore une « surveillance » de ce qui y est fait, je pense par exemple à petitions qui est toujours utilisé sur spip.net par exemple. Mais, comme la branche master est en mode protected il n’y a pas trop de danger, et les personnes qui sont intéressées pour suivre ces plugins pourront très bien s’abonner à leur repo. Donc +1
Sur ce point tu dis « et continuer d’utiliser les outils de @marcimat tels quels » : ça voudrait dire que si on les passe au même cycle de vie que spip/spip on pourrait se passer des outils en question ? Si oui, +1 plein de fois !
pour les groupes, actuellement, je pense que les forces vivent sont les mêmes
pour sortir les vieux plugins-dist, pourquoi pas, cela aura le mérite de simplifier la lisibilité. Par contre, certains plugins-dist fonctionnent correctement que s’ils sont dans le sous dossiers plugins-dist et non plugins. (ex : jquery-ui)
Tout à fait. Mais la logique de dev/maintenance non.
2 groupes gitlab permettraient de mettre en place des automatismes sur l’un sans les appliquer aux projets de l’autre ET d’éviter ainsi une gestion d’exceptions et de cas particuliers dans les outils (quel-qu’ils soient)
C’est une possibilité pour le futur, peut-être, mais ce serait aussi l’occasion d’en simplifier le code, la logique.
j’ai écrit spip-contrib-extensions mais ça pourrait être, au cas par cas, galaxie, grenier (encore que j’ai d’autres propositions à faire dans ce cas, mais ça va au delà de la maintenance telle qu’on en parle ici …)
Je ne suis pas très chaud à ce que les plugins-dist aient des versions qui suivent SPIP… ça veut dire que si tu sors un SPIP 4.2.13, tu tagguerais tous les plugins-dist avec ce numéro, même s’il n’a eu aucun changement dessus… c’est ce qu’il y avait avant… et ça prenait bien plus de temps de release (car il faut du coup passer sur tous les plugins-dist même s’ils n’ont eu aucun changement).
L’objectif étant, il me semble de s’appuyer plus sur Composer, comme dans SPIP 5 pour gérer les dépendances des plugins-dist, je trouve peu pertinent cette démarche, qui n’indiquerait plus dans le numéro de version les changements réels des contenus des plugins-dist en question (plus de semver dessus quoi au final).
Bref, pas favorable du tout sur ce point là. Alors oui, je comprends que ce n’est pas évident de voir «quelle branche de tel plugin-dist est utilisé sur telle version de SPIP»… mais ça ne me semble pas non plus la fin du monde. Par ailleurs les Changelog introduits aident bien mieux à suivre les évolutions je trouve.
Pas plus d’avis que cela : mais effectivement ces composants ne sont pas du tout codés de la même façon que SPIP / les plugins-dist, sont de vrais packages, avec des tests unitaires autonomes, et il pourrait y avoir dans ce groupe une gestion plus automatisée de certaines choses (CI particulièrement).
Ils pourraient pourquoi pas en ce sens être logés dans un groupe spécifique plus identifié.
En dehors de ça, c’est pas une obligation en tout cas, c’est peut être juste un côté identifiable / pratique
Pourquoi pas… pas sûr que ça apporte plus de PR dessus, mais ça pourrait permettre d’exprimer que c’est pas forcément aux mainteneurs du core uniquement de s’en occuper et les faire évoluer.
Plutôt pour les vieux plugins-dist ailleurs, pour mieux signifier que c’est plus le core qui s’en occupe (et même s’ils ne bougent pas plus ensuite, mais au moins pour augmenter leur borne max de compat quand des gens testent), et aussi comme le dit @maieul pour les rendre plus rapidement installables notamment pour les vieux sites qui reposent dessus (jquery UI etc par ex).
Plutôt pour mettre les vrais composants PHP dans une orga dédiée, ne serait-ce que pour la com/visibilité en premier lieu.
Pour les tags des versions, comme @marcimat, il me semble qu’on avait déjà eu cette discussion pour choisir et que le but était de suivre semver partout, à la fois pour… qu’il y ait un sens (le numéro veut alors vraiment dire quelque chose) et aussi pour pas aller taguer et brancher en masse 100% des plugins-dist à chaque release : juste à changer les JSON de dépendances, c’était ça l’énorme avantage.
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.
Et donc non les plugins-dist évoluent ou pas entre chaque release, et si ya pas d’évolution ya pas de raison de leur changer leur version.
Mais ce que j’ai pas encore compris pour quelles raisons concrètes ya besoin de connaitre super rapidement la compat des plugins-dist ? Dans quels buts, pour en faire quoi ?
Il me semble que dans la balance : cette info est déjà dans les XML + dans les JSON de SPIP, donc existante et pas cachée (et parsable par des algos !), et que cela est suffisant par rapport au gros avantage de plus modifier les plugins à chaque release.
Mais t’es point censé installer un plugin-dist via Git seul à l’unité , c’est soit spip-cli soit plus tard composer, qui est censé faire ça (justement avec les JSON qui déclarent bien quelles versions utiliser). Si c’est quand même le cas (mais je ne pige pas encore le cas d’usage), ça représente vraiment une infime partie des utilisations pour les plugins-dist (on parle bien que des plugins-dist là), donc les infos JSON+XML suffisent largement pour les rares power-users qui en ont besoin.
Ça n’est pas ce que j’avais compris dans la proposition de @JamesRezo : je pensais qu’il roposait d’avoir une branche X.Y des plugins-dsit pour la branche X.Y de SPIP, mais sans se préoccuper de Z. Je laisse @JamesRezo confirmer/infirmer
Sur la decorrolation plugins-dist/spip sur les versions.
Permettre de garder du vrai versionnement sémantique permettrait par ex d’indiquer pour un plugins (pas dist) qui dépend d’un plugin dist qu’il est bloqué sur une version X de ce plugin dist.
Et donc si jamais entre par exemple la 4.2 et la 4.3 de SPIP le plugin-dist en question passe à X+1 on sait que le plugin ne sera pas compatible immédiatement. Autrement dit : on a plus de granularité / finesse pour gérer les bornes de compatibilité.
Je propose de renommer leurs milestones avec ces numéros de versions et de supprimer les branches non-maintenues (<= SPIP 4.1), sans supprimer les tags, bien évidement.
Pour les milestones :
soit je fais comme pour spip/spip: nom de milsetone = nom de branche,
Je supprimerai aussi les milestones spip-4.3 qui ne sont pas nécessaires quand on a une version de plugin commune pour spip/spip >=4.2 et <5.0, aprés avoir déplacé les 2 issues/PRs qui leur sont associées.
)
