Dernièrement, en créant quelques tickets, j’ai remarqué que les milestones des plugins-dist ne sont pas à jour. En effet, on a maintenant des branches .X (genre 4. sur sites), mais pas les milestones correspondantes. Je pense qu’il faut faire le tour des plugins dist et réer les milestones manquantes. Concernant leur date d’échéance, on doit pouvoir l’aligner sur la date de fin de support annoncé pour SPIP 4.4 (?) De ce que je vois dans plugins-dist.json · 4.4 · spip / spip · GitLab ça ne concerne que les plugins mediabox & sites.
Autre point, on a encore des tickets liés à des milestones expirées liées à SPIP 4, exemple ici Jalons · spip / sites · GitLab
Que fait-on de ces tickets ? Est-ce qu’on les déplace sur la dernière milestone SPIP 4 de ces plugins ? Le fait-on en masse à l’aide de l’API (ping @JamesRezo) ? Ou alors on laisse « les gens » le faire au fur et à mesure quand on repère qu’un ticket est sur une milestone expirée ?
Autre point, la plupart des milestones des repos de l’orga spip sont expirées, et pour cause on a décalé la date de fin de support de la branche 4. Exemple avec le repo prive Jalons · spip / prive · GitLab ou medias Jalons · spip / medias · GitLab
Que fait-on pour les dates de fin de ces milestones ? On s’attelle à un travail en masse pour mettre à jour leur date de fin (avec l’éventualité de devoir la mettre à jour au prochain décalage de fin de support, etc) ou on supprime simplement ces dates de fin ?
Je ne sais pas quoi te dire là dessus pour les dates.
Je me demande cela dit s’il ne faudrait pas passer toutes les branches de maintenance en .x sur les plugins, et faire des X+1 sur leurs branches main/master (ce qui risque encore de nous faire supprimer des tags existants sur ces brances issus de la 5.0-beta, ce qui est très relou, mais je vois pas trop comment faire autrement, ça nous ennuie plus qu’autre chose…)
Au fait, on a fait un petit point en visio hier pour discuter différents points relatifs à SPIP 5 une partie de l’équipe maintenance. Notamment pour ces deux points :
On va passer l’ensemble des plugins-dist avec des noms de branches en .x pour les branches de maintenance ; il y aura donc master ou main pour la branche de dev, relative à SPIP 5, et une branche telle que 3.x ou 2.x… pour la branche de maintenance relative à SPIP 4.4.
Il y a plusieurs raisons à cela :
d’une part pour respecter au mieux la convention de versionnage sémantique, on a déjà du le faire déjà pour certains plugins (mediabox, sites notamment),
d’autre part on se doute que la maintenance de SPIP 4.4 va durer longtemps, et qu’il y a de grandes chances de devoir de faire des incréments autre que .z sur ces plugins-dist, notamment si on doit ajouter de nouvelles fonctions pour des raisons de sécurité.
enfin cela va harmoniser la situation entre les plugins, et faciliter la gestion des branches de maintenance.
En conséquence,
les branches master / main vont avoir leur paquet.xml incrémentés sur X (si la branche de maintenance est 3.x, master / main passera en alias 4.0.x-dev grosso modo, avec son paquet.xml adapté)
certains tags existent sur master qui ennuient (ceux qui ont été générés pour la 5.0.0-beta d’il y a bien longtemps) : on peut avoir une version 3.3.10 pour SPIP 4.4 et 3.4.0 pour SPIP 5, et ça devient un problème dès lors que l’on va passer en branche 3.x (On ne pourrait pas générer de version 3.4.0 vu qu’elle existe déjà en tag). Du coup, nous allons supprimer ces tags relatifs à SPIP 5.0-beta, ce qui va causer des troubles lors des mises à jour en GIT : En faisant git pull sur le dépôt, ou en utilisant l’outil checkout également, Git râlera à juste titre dès lors qu’on recréera ailleurs ce tag 3.4.0, si ce tag n’a pas préalablement été supprimé localement. Pour cela il y a plusieurs méthodes, mais git fetch --prune --prune-tags fait ce taf par exemple… Une config git peut le faire automatiquement sans avoir besoin de passer les options (git config fetch.pruneTags true)
Sur les milestones : on ne mettra pas de date de milestone sur les branches en .x , en tout cas pas pour le moment, du coup, elles n’apparaîtront pas comme « expirées » à chaque fois que l’on décale notre calendrier…
J’ai passé tous les plugins dist en branches .x donc pour SPIP 4.4, adapté les master pour SPIP 5, supprimé les tags qui pouvaient être gênants, configuré plugins-dist.json et spip/classic-distribution. A priori c’est correct, même si ce fut bien long.
Je vous laisse voir pour les milestones @b_b ou @JamesRezo ou qqn·e d’autre !