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 pullsur le dépôt, ou en utilisant l’outilcheckouté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, maisgit fetch --prune --prune-tagsfait 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…