Re: [spip-dev] Les branches spip-3-stable

From : james@... , the 16th mars 2018 17:37

Le 16 mars 2018 à 14:26, Jean Marie Grall  a écrit :
 Salut,  moi qui utilise ces branches stables (et constate/signale les oublis quand  il y en a), si je peux me brancher sur les tags au lieu des branches, ça me  va tant que j'ai du stable... c'est équivalent ?
TL;DR : oui, c'est équivalent, mais tu utiliseras plus souvent "svn switch" que "svn up" pour tes montées de version ! :) Alors : C'est équivalent les tags et les branches ? Presque. On peut se figurer que les tags, ce sont des branches qui ne bougeront plus. Ok, c'est un abus de langage, mais c'est pour expliquer. Avec SVN comme outils de gestion de version, il n'y a aucune contrainte ni limite technique à organiser les opérations de développement, de maintenance et de publication (release) d'un logiciel. On peut créer des répertoires comme on veut, où on veut. C'est aussi avec le même outil que l'on peut copier des répertoires entiers d'un emplacement à l'autre dans le dépôt central d'une part, et associer sa copie locale avec le répertoire que l'on souhaite dans ce même dépôt, d'autre part. Et, contrairement à BitKeeper, Git, etc, c'est la seule chose que SVN sait faire, gérer des répertoires. Mais comme au bout d'un moment, il devient nécessaire pour l'équipe en charge des opérations d'organiser les phases de dev/maintenance/release, des conventions ont émergé et on s'est mis à parler de branches. Dans SVN, pour les représenter et puisqu'il n'y a que des répertoires pour le faire, a émerge la convention suivante : à la racine du dépôt (ou à l'emplacement dans le dépôt destiné à un logiciel), on créé un répertoire pour le développement, un répertoire pour la maintenance, un répertoire pour la publication : trunk, branches, tags. Et comme la publication a vocation à garantir une distribution d'un logiciel sans risque de changement, l'équipe s'engage à ne jamais modifier les copies du logiciel présentes dans le répertoire tags. Donc, dans SVN, tout est branche, puisque tout est répertoire. Il est donc possible de "se brancher" où on veut et changer de "branche" quand on veut. Techniquement, ça donne ça : Si tu veux être dans la future version, tu prends la branche spip. Si tu veux être dans la dernière 3.x de maintenance, tu prends la branche branches/spip-3.x, avec x la dernière sous-version, et "svn up" pour mettre à jour ta copie locale, Si tu veux être dans une version de maintenance précédente, tu prends la branche d'une version précédente (branches/spip-3.1 par exemple), et "svn up" itou Si tu veux être sur une version "stable", tu prends le tag d'une version stable (tags/spip-3.2.1, par exemple), c'est stable, ça bouge plus. Si tu veux changer de branche, tu utilises "svn switch" Le jour où tu souhaites passer d'une version "stable" à une autre : "svn switch" Si tu ne sais pas quelle version stable est la dernière : "svn ls svn:// trac.rezo.net/spip/tags" te donnera la liste de toutes les releases La question est finalement de savoir si "svn switch" est une bonne pratique, ou pas. Si elle est plus dure à utiliser que de faire un "svn up" sur tes environnements de production tout le temps jusqu'au jour ou la branche de maintenance stable que tu pointait disparait, ce qui t'obligera à faire un "svn switch" pour passer à la suivante. Au delà de la communauté SPIP, il y a eu plein de débats sur le fait de savoir si utiliser un outil de gestion de version (svn ou git) pour faire ses déploiements en prod est une bonne chose. Il en va de même des outils de gestion de dépendances (maven, bundler composer, npm, etc.). En gros, pour revenir à SPIP, il n'y a pas d'alternative autre que SVN ou les ZIP pour le déploiement. Bon, ça ne fait pas avancer le débat sur le maintien des branches de maintenance stable, mais j'espère que ça répond à ta question ;)
 Mais j'avais cru comprendre que les tags, c'était mal, non ?
Compte-tenu de ce qui est dit plus haut, non, ce n'est pas mal. :-)
 Bon, ben, bisou aussi alors :)              jean marie
Amitiés, -- James PS: ça aurait fait un chouette billet pour spip.blog, ça :)