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,
