En date de : Lun 13.7.09, Gilles VINCENT <gilles.vincent@gmail.com> a écrit :
[...]
Rappel du fonctionnement du trunk (ou dépôt de
référence) :- Le principe du trunk est de mettre à disposition une
branche stable de référence. Un checkout sur le trunk doit
toujours être fonctionnel avec la dernière version spip
compatible : ça peut d'ailleurs très bien être une
1.9.2.
- En principe, on ne fait pas de développement dans
le trunk, mais dans une (ou plusieurs) branche
séparée.- Cependant plusieurs projets qui
utilisent Subversion ont choisi de faire des développements
directement dans le trunk : c'est le cas lorsqu'on a
des modifications atomiques simples à contrôler. C'est
ce qui se passe actuellement avec SPIP (et Subversion
lui-même). La contrainte qu'on doit garder cependant
est la stabilité globale.
mais du fait de cet usage pour SPIP, j'avais toujours eu l'impression qu'au contraire "trunk" correspondait à la branche de développement! et j'imagine ne pas être le seul dans ce cas... du coup est ce vraiment pertinent de ne pas garder ça comme rêgle de fonctionnement pour tout ce qui touche à SPIP (i.e. la zone)?
Pour les plugins sur lesquels j'ai commité et
concernés par l'affaire je préfèrerais donc:# saveauto:
_plugins_/saveauto/branches/spip-1.9.1
_plugins_/saveauto/branches/spip-1.9.2
_plugins_/saveauto/branches/spip-2.0En effet, on peut très bien se passer de trunk
dans le cadre d'un plugin.Mais le risque que
j'y vois est une multiplication à terme des branches :
que vas-tu faire pour spip-2.1, spip-2.2, etc. ?
ça dépend: si SPIP 2.1 nécessite une modif du code du plugin alors je ferais un _plugins_/saveauto/branches/spip-2.1
Au contraire si la version actuelle tourne sans modifications sur SPIP 2.1 (ce qui est le cas il me semble), alors je me mordrai les doigts de ne pas avoir fait _plugins_/saveauto/branches/spip-2 ce qui aurait permis de ne rien avoir à faire...
Tu soulèves cependant un point intéressant :
On ne sait pas si la branche spip-2.0 est stable ou
pas.C'est peut-être ici que le statut du
plugin défini dans plugin.xml peut être intéressant : il
serait à l'état de dev (ou test) dans la branche
spip-2.0, et stable dans les 2 autres.
le coeur du problème me semble plutôt:
1/ je me fous de savoir si la branche spip-2.0 de saveauto est stable ou non: si c'est la seule qui existe pour SPIP 2.0 je l'utilise quel que soit son état. Dans l'idée, pour cette indication de stabilité c'est le <statut> du plugin.xml qui me renseigne
2/ En revanche, si je prend le cas du plugin odt2spip par ex, il existe 1 version qui tourne sur SPIP 1.9.2 *et* SPIP 2.0. et une autre version qui tourne sur SPIP 2.0 *et* SPIP 2.1 utilisée pour le dev: les choses sont explicitement faites dans le SVN:
_plugins_/odt2spip/version_0.1_stable
_plugins_/odt2spip/version_0.2_dev
seule la version 0.1 étant portée dans le archiveliste.txt donc dispo par zip
On pourrait imaginer de mieux structurer les
branches au niveau de svn
_plugins_/saveauto/branches/stable/spip-1.9.1
_plugins_/saveauto/branches/stable/spip-1.9.2
_plugins_/saveauto/branches/dev/spip-2.0
Comme cela la situation est
limpide pour celui qui récupère le plugin via svn (moins
par celui qui le récupère via l'archive, si on ne
donner pas un nom spécifique de type saveauto-dev-2.0.zip
et saveauto-stable-1.9.1.zip -- c'est un autre débat --
)
Qu'en dis-tu ?
j'en dis: KISS !!!
l'idée de re-démultiplier l'arborescence du SVN de la zone ne me semble pas souhaitable (trop pénible à explorer même avec tortoise!)
Alternativement je préfèrerais:
_plugins_/truc/spip-1.9.1
_plugins_/truc/spip-1.9.2
_plugins_/truc/spip-2
avec éventuellement pour les zips prise en compte du <statut> du plugin.xml pour générer:
truc_spip-1.9.1_stable.zip
truc_spip-1.9.2_stable.zip
truc_spip-2_test.zip
Enfin, dernier point à prendre en compte amha: chaque changement de l'arborescence du SVN de la zone oblige à toute une série de svn-switch pour tous ceux qui utilisent SVN (et surtout ceux qui ont des serveurs sur lesquels ils gèrent les mises à jour via SVN).
La mise à plat de Ben était relativement le cas de figure idéal puisque la destination du switch était prédictible facilement donc il a été possible d'automatiser les switch avec un script sh/svn. Dans l'idée il me semble qu'il *doit* pouvoir être possible de faire le même genre d'automatisme si une nouvelle organisation est adoptée... (on va dire: le bénéfice du renommage doit être supérieur à la pénibilité de l'opération de switchage de l'existant!)