Il est probable qu’on s’occupe dans le week end (demain?) de renommer les branches & tags de SPIP et des plugins-dist, tel que proposé dans un thread précédent (Release, Git, Composer - du 14 septembre dernier).
Tout le monde semblait partant (je n’ai pas vu de contre indication en tout cas !).
Je pense ajouter également, enfin remplacer plutôt, le fichier .gitsvnextmodules par un fichier spip_modules.json ou quelque chose comme ça dans les branches 3.1+. Ce fichier listerait simplement l’url des Gits des plugins-dist (sans préciser la branche ou tag) et le répertoire destination. Encore une fois ce n’est pas quelque chose (ce fichier) qui sera pérennisé (l’idée est tout de même pour les futurs développement d’aller vers un composer.json)
Les outils checkout et spip-cli seront temporairement cassés et devront être mis à jour. J’essaierai de m’occuper de checkout.
Je n'ai pas les mains dans Spip depuis début juillet, mais je continue à suivre les échanges de Spip-dev et la zone, et tout le travail des piliers de Spip.
J'espère aussi que vos proches et vous avez la forme,
et j'envoie aussi un peu de tendresse charentaise à toutes & tous.
Pour des SPIP 3.2 ou 3.3 déjà installés en Git avec checkout, on pourra avoir un guide ou les commandes qui vont bien pour mettre à jour ?
Ça consistera surtout à changer les remotes ou les branches, non ?
Les tags des versions ont été homogénéisés selon semver, avec les pre-release séparés par - et éventuellement '.'. Des releases spéficiques (a à z sont séparés par +, comme des «build» au sens semver). Exemples (j’ai plus les vrais en tête) :
J’ai envoyé un premier pas avec une version 1.4.0 de checkout.
Ce n’est qu’une première étape (plugins-dist.json n’est pas encore introduit), mais ça télécharge ou met à jour un SPIP ce qui est déjà pas si mal.
J’ai ajouté un lien aussi sur la commande 'checkout' exécutable, vers checkout.php d’avant pour avoir un nom de commande identique entre Windows et MacOs/Linux. Et adapté le readme en conséquence.
Cependant checkout ne supprime pas les branches ou tags qui ont été supprimé sur le dépot distant.
Les branches suivies localement auparavant sont conservées. Typiquement si vous étiez en 'spip-3.2' vous aurez une branche '3.2' active (le nouveau nom), qui suit origin/3.2, et une branche 'spip-3.2' présente d’avant, qui suit origin/spip-3.2 qui n’existe plus (car enlevé avec le --prune).
Cette branche locale spip-3.2 peut donc être supprimée.
C’est pareil pour les plugins dist (dans l’autre sens).
Voilà, tout est à peu près fait pour ce que j’indiquais (reste plus qu’à vérifier tout ça)
- un fichier plugins-dist.json est présent dans les 3 branches master, 3.2 et 3.1 et est utilisé de préférence par l’outil Checkout (à mettre à jour) (lonsqu’on lance 'checkout spip ...')
- un mini script très très à l’arrache http://spip.pastebin.fr/66841 nettoie les branches et tags supprimées du remote 'origin' ; ça peut aider...
/!\ Attention (cher développeureuse de SPIP) à ne pas faire de `git push --tags` à un moment après ta mise à jour, sans avoir fait par exemple un `git fetch origin --prune --prune-tags` avant sur ton projet pour ne pas repusher tous les anciens tags d’un coup (ça serait ballot) ! Note que git push a une option --dry-run qui permet de voir et vérifier ce qui va être envoyé.
Matthieu Marcillaud a écrit le 28/09/2020 à 02:12 :
Voilà, tout est à peu près fait pour ce que j’indiquais (reste plus qu’à vérifier tout ça)
- un fichier plugins-dist.json est présent dans les 3 branches master, 3.2 et 3.1 et est utilisé de préférence par l’outil Checkout (à mettre à jour) (lonsqu’on lance 'checkout spip ...')
Merci.
Testé avec succès en local.
Juste un détail : spip-contrib-outils / checkout · GitLab indique :
checkout spip -bspip-3.2 dossier_destination
mais maintenant, c'est :
checkout spip -b3.2 dossier_destination
- un mini script très très à l’arrache http://spip.pastebin.fr/66841 nettoie les branches et tags supprimées du remote 'origin' ; ça peut aider...
