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é.
En prenant l’hypothèse qu’il y a consensus sur la conversationconservation des numéros de version x.y des plugins pour leurs branches le groupe spip :
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 :
spip/spip: nom de milsetone = nom de branche,aide-3.2. Ainsi, les pages https://git.spip.net/groups/spip/-/merge_requests, https://git.spip.net/groups/spip/-/issues et https://git.spip.net/groups/spip/-/milestones nous permettront de distinguer les versions de spip et de chaque plugins-dist.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.
PS: Et, oui, j’avais vu pour medias …
Une remarque en passant :
Donc,
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.
merci, ca me parait bien
soit j’ajoute le prefix du plugin devant. Ex:
aide-3.2. Ainsi, la page Requêtes de fusion · spip · GitLab, Tickets · spip · GitLab et Jalons · spip · GitLab nous permettront de distinguer les versions de spip et de chaque plugins-dist.
a partir du moment ou un meme groupe contient des projets avec un système de numerotation différent, je pense qu’effectivement il faut préfixer.
Voilà qui est fait.
petitions a bien sa branche master protégée, mais c’est le cas pour tous les plugins déplacés
Merci pour les déplacements !
Pour pétitions et trad.lang/salvatore je ne sais pas si on a fait quelque chose de spécial pour qu’il puisse commiter sur spip qui a déjà une branche protected.
Concernant les milestones ça m’a fait bizarre au début, mais au final c’est assez simple : le numéro le plus haut est la branche de dev donc le master de SPIP, la suivante pour la/les versions stables, et la dernière pour la version sécu only. Si ça ne change pas à l’avenir (et ça ne devrait pas), on peut s’y retrouver sans aller lire le paquet.xml du plugin.
Ah oui… oki, pourquoi pas.
Du coup, est-ce qu’il faut changer le namespace dans le composer.json et les fichiers PHP ?
j’y pense, mais ça me semble pas urgent. C’est pas bloquant, mais ça fait parti des trucs qui auraient du sens. Et on pourrait en causer avec la team @architecture ?
Ah oui, j’oubliai …
x.y) de spip/spip non-maintenues (quand on veut)Juste un détail sur images 4.2 et medias 4.3 : leur borne de compatibilité est en [4.2.0; et non en [4.3.0; ce qui fait qu’ils apparaissent dans les plugins bénéficiant d’une mise à jour si on va voir les plugins verrouillés d’un SPIP 4.2.
2 solutions :
[4.3.0;, faire un nouveau tag, effacer les anciens tags et zipdéjà, rien que cette phrase …
Comme on se le disait en audio tout à l’heure, ça n’est problématique que pour les gens qui utilisent la fonctionnalité que tu as ajouté pour indiquer les mise à jours des plugins-dsit cf Les infos de nouvelles version ne sont pas affichées pour les plugin mis dans dist (#4909) · Tickets · spip / svp · GitLab Je suppose donc que tu sais ce que tu fais avec tes plugins-dist 
De plus, si je ne me trompe pas, ces plugins ne peuvent pas être mis à jour depuis l’interface.
D’un point de vue de la distribution standard il n’y a aucun problème, la branche 4.2 cible bien la branche 4.2 de medias cf plugins-dist.json · 4.2 · spip / spip · GitLab et la branche 4.3 de SPIP cible bien la branche 4.3 de medias.
J’ai souvenir d’en avoir déjà discuté avec les autres, mais je ne me souviens plus pourquoi on a fait le choix de garder ces bornes de compat. Si ça ne nous coûte rien de les changer, on pourra le faire bien sûr.
J’ai une question sur ce point : comment on fait pour installer un vieux SPIP, ce qui est parfois la seule solution pour récupérer un site existant avant de le mettre à jour ?
C’est vraiment que branche et ça garde par contre tous les tags et ZIP et du coup ya aucun soucis ? (juste pour être sûr)
Je n’ai fait que rajouter que ça affiche le n° de version cible. Ça affichait déjà qu’il y avait des mises à jour.
Remplace « Vérouillés » par « Tous » dans cette phrase, ça sera plus digeste 
Si je ne dis pas de bêtise, oui, les tags restent même si la branche est supprimée.
Exactement comme les plugins-dist, tout à fait.
Ok super, c’est parfait
Refresh là-dessus :
x.y) de spip/spip non-maintenues
TODO :
) → Outils de changelog