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.
le plugin petitions a bien sa branche master protégée, mais c’est le cas pour tous les plugins déplacés
reste à voir s’il y a des changements à faire pour trad.lang …
j’ai créé le groupe spip-league, il est public et accessbile en lecture et toustes, les membres de la team @architecture ont accès en lecture/écriture. Le dépôt composer a été mis à jour suite au changement d’url des projets déplacés.
les milestones des plugins-dist sont nommées en fonctions des branches maintenues
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.
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 ?
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 :
considérer qu’ils seront backportés dans les plugins-dist de SPIP 4.2 à la sortie de SPIP 4.3 et laisser ces bornes
changer les bornes en [4.3.0;, faire un nouveau tag, effacer les anciens tags et zip
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)
Flux RSS contrib : il a fallu que j’aille forcer le refresh de la syndication auto, mais OK
Suppression des branches de maintenance (x.y) de spip/spipnon-maintenues
Modèles pour générer la base d’articles de releases sur le blog.
TODO :
Envoyer le changelog dans le blog pour l’editorialiser avant publication (@b_b, @marcimat : faut qu’on rediscute des outils de gestion de CHANGELOG ) → Outils de changelog
Automatisation de la mise à jour des référentiels de pre-releseases et de releases du plugin supported-versions
à discuter, le test/proposition de la mise en place d’un dépôt spip / classic-distribution · GitLab qui rassemble les versions des composants d’un SPIP « classique », qui je pense, pourrait nous aider à nous simplifier la vie pour le suivi des versions des plugins-dist etc.