Fluidifier la création de releases

Une remarque en passant :

  • medias 4.3 est marqué dans son paquet.xml comme compatible SPIP 4.2
  • Et comme il a un tag, SPIP 4.2 l’indique comme disposant d’une mise à jour

Donc,

  • soit il faudrait l’intégrer à SPIP 4.2
  • soit supprimer le tag et indiquer une compat à partir de 4.3 seulement

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.

1 « J'aime »

Voilà qui est fait.

  • les « vieux » plugins-dist sont déplacés
  • 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

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 ?

P’tite màj des versions des plugins-dist avec la release du jour (et la branche 4.4)

Ah oui, j’oubliai …

  • Topic d’annonces auto : OK :white_check_mark:
  • Flux RSS contrib : il a fallu que j’aille forcer le refresh de la syndication auto, mais OK :white_check_mark:
  • TODO : suppression des branches de maintenance (x.y) de spip/spip non-maintenues (quand on veut)
  • TODO : Automatisation de la mise à jour des référentiels de pre-releseases et de releases du plugin supported-versions (un de mes prochains chantiers)
  • TODO : Modèles (ou trucs équivalents) pour générer la base d’articles de releases sur le blog.
1 « J'aime »

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

1 « J'aime »

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

Si je ne dis pas de bêtise, oui, les tags restent même si la branche est supprimée.

2 « J'aime »

Exactement comme les plugins-dist, tout à fait.

1 « J'aime »

Ok super, c’est parfait

2 messages ont été scindés en un nouveau sujet : Ménage dans les branches abandonnées

Refresh là-dessus :

  • Topic d’annonces auto : OK :white_check_mark:
  • Flux RSS contrib : il a fallu que j’aille forcer le refresh de la syndication auto, mais OK :white_check_mark:
  • Suppression des branches de maintenance (x.y) de spip/spip non-maintenues :white_check_mark:
  • Modèles pour générer la base d’articles de releases sur le blog. :white_check_mark:

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 :wink: ) → Outils de changelog
  • Automatisation de la mise à jour des référentiels de pre-releseases et de releases du plugin supported-versions
1 « J'aime »

à 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.

J’ai pas trop compris, c’est quoi la différence avec spip/spip du coup qui déclare déjà chaque plugins-dist, enfin il me semblait ?