est-ce que vous êtes pour l’utilisation de tags sur le svn ?
A mon avis ça a l’avantage de faciliter la maintenance, en s’assurant que quelqu’un qui récupère une version stable n’ait pas récupéré une version intermédiaire avec des modifs pas complètement testées.
Autre avantage : c’est cohérent avec les fichiers disponibles à http://trac.rezo.net/trac/spip/ et http://www.spip.net/fr_download
Un tag correspond à une version officielle et se distingue d’une branche qui est un espace de maintenance (et prépare la prochaine version stable officielle).
L’utilisation de tags non génériques (pour 2.07, 2.06, etc…) permettrait de s’assurer dans les tests qu’il n’y a pas de régression entre 2 versions stables officielles.
pourquoi pas oui, cela permet de mettre à jour par svn pour quelqu'un
qui veut suivre les versions stables
j'ai pas trop compris le jeu, svn switch c'est compliqué, quand il
s'agit de changer de branche stable ?
Ca évite de rechercher un numéro de commit qui correspond à une version pour ensuite faire un update à la bonne révision.
svn copy -r 13982 svn://trac.rezo.net/spip/branches/spip-2.0 \
svn://trac.rezo.net/spip/tag/last-stable-version \
-m "Tagging the 2.08 release of SPIP."
visiblement ça permet de coder en franglais
mais je suis perplexe pour la commande quand on sort la 2.0.9
il faut refaire une copie ?
et comme une fois sur deux on se rate, ça risque d'être encore plus amusant
ben moi je trouve ça bien de faire des tags.
Ca permet effectivement de remonter sur des versions stables identifiées en utilisant svn, et ça ne coute rien en espace de stockage.
Ca permettrait de remplacer avantageusement le tableau de
mais je suis perplexe pour la commande quand on sort la 2.0.9
il faut refaire une copie ?
Un tag (on utilise aussi le terme de « Jalon ») n’est rien d’autres qu’une branche qui n’est pas modifiée.
Pour la 2.09, il suffit de faire un « merge » entre la branche spip-2.0 et le tag latest-version
pourquoi pas oui, cela permet de mettre à jour par svn pour quelqu’un
qui veut suivre les versions stables
j’ai pas trop compris le jeu, svn switch c’est compliqué, quand il
s’agit de changer de branche stable ?
Je ne pense pas qu’il faille utiliser le svn switch pour distribuer la dernière version officielle.
Le fait d’avoir des tags pour les anciennes versions permet de rapidement répondre à la question
« J’ai spip 2.05 et j’ai tel problème… »
autrement que « ça marche chez moi » ou « tu n’as qu’à mettre ta version à jour – au risque de planter des plugin etc. »
Arf, l’exemple était à la base pour la liste spip-en ^^
Donc oui, c’est bien pour du franglais
mais je suis perplexe pour la commande quand on sort la 2.0.9
il faut refaire une copie ?
et comme une fois sur deux on se rate, ça risque d’être encore plus amusant
svn merge suffit : on reporte les modifs faites depuis la dernière version stable (et reportée sur branches/spip-2.0) sur la branche tags/latest-version (ou tags/derniere-version ou les puristes )
Et en même temps on en profite pour créer un nouveau tag pour la 2.09
— Merging r13983 through r14025 into ‹ tags/version-officielle ›:
U tags/version-officielle/prive/transmettre/statistiques.html
U tags/version-officielle/prive/transmettre/statistiques_article.html
U tags/version-officielle/prive/formulaires/editer_rubrique.html
U tags/version-officielle/prive/rss/forums_public.html
U tags/version-officielle/ecrire/exec/articles_edit.php
U tags/version-officielle/ecrire/exec/articles_forum.php
U tags/version-officielle/ecrire/exec/articles.php
U tags/version-officielle/ecrire/exec/rubriques_edit.php
U tags/version-officielle/ecrire/exec/naviguer.php
U tags/version-officielle/ecrire/inc_version.php
U tags/version-officielle/ecrire/inc/plugin.php
U tags/version-officielle/ecrire/inc/minipres.php
U tags/version-officielle/ecrire/inc/utils.php
U tags/version-officielle/ecrire/inc/filtres_images.php
U tags/version-officielle/ecrire/inc/filtres.php
U tags/version-officielle/ecrire/inc/presentation.php
U tags/version-officielle/ecrire/public/stats.php
U tags/version-officielle/ecrire/public/compiler.php
U tags/version-officielle/ecrire/public/balises.php
U tags/version-officielle/ecrire/public/interfaces.php
U tags/version-officielle/ecrire/public/phraser_html.php
et comme une fois sur deux on se rate, ça risque d'être encore plus
amusant
J'en profite pour proposer un script qui automatise la mise à jour de la
dernière version stable :
Ah ça c'est plus parlant anéfé, je suis "pour" aussi, donc. Par contre
si on pouvait appeler ça "stable" et pas "version-officielle" ça me
ferait plaisir Ou alors il faut la limousine et les gendarmes à
moto.
Ah ça c’est plus parlant anéfé, je suis « pour » aussi, donc. Par contre
si on pouvait appeler ça « stable » et pas « version-officielle »
je ne savais pas que les commits sur la branche stable la rendaient instable ?
Pour ma part, voilà comment je perçois l’espace de dev.
La branche « stable » est, telle que c’est utilisé pour SPIP, la branche qui prépare la prochaine version stable.
La branche principale est le laboratoire dont les modifs les plus intéressantes, une fois mûres, sont intégrées dans la branche stable.
Mais il n’y a pas de contrainte de stabilité réelle dans la branche « stable » : il y en a lorsqu’on sort une nouvelle version majeure (un peut moins pour une version mineure).
La pratique observée a toujours été, je concède, de garder le maximum de stabilité sur la branche stable qui est souvent utilisée en prod. Merci aux développeurs qui ont maintenu cette branche optimale !
Ah ça c’est plus parlant anéfé, je suis « pour » aussi, donc. Par contre
si on pouvait appeler ça « stable » et pas « version-officielle »
je ne savais pas que les commits sur la branche stable la rendaient instable ?
Pour ma part, voilà comment je perçois l’espace de dev.
La branche « stable » est, telle que c’est utilisé pour SPIP, la branche qui prépare la prochaine version stable.
ben non la prochaine stable se prepare dans dev, la branche « stable » est là pour les corrections de la version majeure à laquelle eslle est associée (2.0) actuellement, les commits fait dessus ne doivent pas la déstabiliser
La branche principale est le laboratoire dont les modifs les plus intéressantes, une fois mûres, sont intégrées dans la branche stable.
C’est pas le cas actuellement, il me semble. Il y a des branches qui évoluent par version « majeure », la plus vivante est la .0 mais il ya tjs des correctifs sur la branche 1.9 (et quelques gros patch de secu meme sur la 1.8)
Ca évite de tout casser quand il ya des rupture de compatibilite entre autre
Les branches accueillent les releases mineures de correctif, quand il y a une majeure (grosses evols/ rupture …) ou crée une nouvelle branche à la sortie de la version pour la maintenir.
Les branches sont donc potentiellment tjs stables ( aux tests pres … ) et le tronc sert aux évolutions.
suite à certains problèmes de stabilité de la branche 2.0, je propose que l’on mette en place le mécanisme de tags.
Les utilisateurs pourraient alors via SVN installer une VRAI version 2.0.8, et non pas une version toujours en mouvement.
Au risque de me répéter, j’ai l’impression qu’on reproduit encore, à plus petite échelle, certaines erreurs de la famille 1.9, en ne séparant pas la notion de “distribution officielle” de la notion de branche de maintenance et/ou de développement.
Il me semble qu’en temps normal, un cycle de développement est constitué de phase de codage, de tests, d’expérimentations, des tests et de stabilisation. Entre 2 phases de stabilisation, des distributions mineures sortent pour corriger des bugs importants (comme c’était le cas pour la 2.0.8). Mais des distrib. mineures ne sont pas sensées être aussi stables que des distrib. majeures car la phase de stabilisation n’a pas été amorcée (avec des versions de pré-sorties de type “beta”, etc…)
Hello,
moi je suis plutôt content du process de dev actuel des branches 2.0 et 2.1 :
on fait des gros devs lourd dans la 2.1, et au fur et à mesure de la stabilisation, on reporte ce qui est possible en branche 2.0.
Quand je dis ce qui est possible, cela sous entend tout ce qui n’entraine pas de regression fonctionnelle ou de rupture de compatibilité.
Du coup on a une branche 2.0 qui vit et profite des améliorations, contrairement à ce qui se passait au moment du dev 2.0/1.9x ou les deux branches avaient tellement divergées qu’il etait quasi impossible de faire de la sorte.
Cela fonctionne bien aussi avec la sortie des fonctions en plugins, qui profitent alors d’enrichissement fonctionnel et de nettoyage de code, et peuvent du coup être utilisées sur la 2.0.x le plus souvent.
Pour améliorer la lisibilité sur le SVN, pas de problème pour moi pour faire des tags correspondants aux releases. On avait dit que le terme ‹ officiel › n’etait pas nécessaire…
Cédric
Du coup on a une branche 2.0 qui vit et profite des améliorations, contrairement à ce qui se passait au moment du dev 2.0/1.9x ou les deux branches avaient tellement divergées qu’il etait quasi impossible de faire de la sorte.
oui, je suis d’accord sur le fait que la proximité entre la version de dev et la branche 2.0 est un réel avantage.
Mais le nombre de reports entre la branche de dev et la branche 2.0 me semble trop important pour que la branche 2.0 ne soit qu’une branche de maintenance : des tas de fonctionnalités lui sont rajoutées au fur et à mesure et demandent à être testées voire améliorées (pourquoi pas développées directement dans la branche 2.0 si la branche de dev s’oriente vers un autre choix).
Cela fonctionne bien aussi avec la sortie des fonctions en plugins, qui profitent alors d’enrichissement fonctionnel et de nettoyage de code, et peuvent du coup être utilisées sur la 2.0.x le plus souvent.
Cela peut impacter les plugins qui sont, eux aussi, pas très structurés en ce moment. Si j’installe une version X d’un plugin qui va dépendre d’une version Y de la branche 2.0, post-2.0.8, je n’ai pas de garantie qu’une autre installation, avec une version 2.0.8 de base (la version[13982]) fonctionne de la même manière.
Il faut distinguer une 2.0.8+dev d’une 2.0.8 sinon on a pas de repère possible.
Ce problème de développement « au fil de l’eau » se produit également avec les plugins, mais là c’est plus compréhensible vu la culture de SPIP ;).
Pour améliorer la lisibilité sur le SVN, pas de problème pour moi pour faire des tags correspondants aux releases. On avait dit que le terme ‹ officiel › n’etait pas nécessaire…
Pas de problème.
Je propose donc simplement comme libellé : « Version 2.0.8 »
Oui c’est normal. Mais il faut considérer cela comme du dev.
Typiquement, sur la mediathèque, la version svn du plugin ne marche actuellement qu’avec la version svn de la branche 2.0
Du coup j’ai mis un sabot sur le zip pour que le paquet tourne avec la version 2.0.8, et je ne releaserai la nouvelle version de la mediatheque que quand la 2.0.9 sera dispo.
Mais au passage, le dev m’a permis de synchro certaines fonctionnalités entre la branche 2.1 et 2.0, de les debug, et ainsi d’améliorer aussi la branche 2.1.
Mais au passage, le dev m’a permis de synchro certaines fonctionnalités entre la branche 2.1 et 2.0, de les debug, et ainsi d’améliorer aussi la branche 2.1.
Oui, et je suis admiratif devant le travail que tu as réalisé pour faire évoluer les deux branches, avec les autres développeurs de la core-team.
du coup quelqu'un se branche sur svn://trac.rezo.net/spip/tags/spip-2-stable
et à la sortie de la 2.0.9 un coup de svn update suffit car on aura fait un
svn copy -r xxxxxsvn://trac.rezo.net/spip/branches/spip-2.0
svn://trac.rezo.net/spip/tags/spip-2-stable
Je suis d'accord avec Gilles, cette abondance pose problème mais pour une raison qui n'a pas été dite: la doc. On a un article qui décrit ce qu'est SPIP 2.0, et la version qui s'appellera à terme la 2.0.9 se met à avoir des fonctionnalités nouvelles qui ne sont décrites nulle part. Evidemment les plugins peuvent s'en sortir avec le numéro SVN, mais ça rend la doc in-maintenable.
En fait cette dérive a pour origine que certains bugs sont plus facilement corrigés en généralisant quelque chose, ce qui provoque une nouvelle fonctionnalité, et je confesse qu'il m'est arrivé d'envoyer des fonctionnalités nouvelles sur la "stable" suite à ce situation. Mais je crois vraiment que çà devrait rester l'exception.
)