Ben voilà, tout est dans le titre. Je m'interroge. Est-il judicieux de démarrer un site sous SPIP 2.0 RC1 sachant que ce n'est pas encore une version stable et que des modifs risquent de me freiner (hypothèse) dans mon travail ou devrais-je mieux me lancer sur la dernière version stable 1.9.2 pour concevoir mon nouveau site, sachant que les ressources documentaires et en contributions sont bien plus nombreuses à l'heure actuelle ?
Merci pour vos réponses,
bruno mercier
* Bruno mercier tapuscrivait, le 27/11/2008 11:31:
Ben voilà, tout est dans le titre. Je m'interroge. Est-il judicieux de démarrer un site sous SPIP 2.0 RC1 sachant que ce n'est pas encore une version stable et que des modifs risquent de me freiner (hypothèse) dans mon travail ou devrais-je mieux me lancer sur la dernière version stable 1.9.2 pour concevoir mon nouveau site, sachant que les ressources documentaires et en contributions sont bien plus nombreuses à l'heure actuelle ?
D'après ta question, tu seras plus à l'aise avec SPIP 1.9.2e.
Mais en même temps, si tu as du temps devant toi, SPIP 2 est beaucoup plus intéressant à utiliser :
- http://marcimat.magraine.net/SPIP-2-se-prepare
- http://marcimat.magraine.net/SPIP-2-se-prepare-suite
Une chose me semble évidente par contre : pour tester efficacement SPIP 2, il _faut_ le faire avec une récupération/mise à jour du code source par SVN (et puisque tu es sous Windows, c'est TortoiseSVN qui te sera utile).
--
RealET
Bruno mercier a écrit :
Ben voilà, tout est dans le titre. Je m'interroge. Est-il judicieux de démarrer un site sous SPIP 2.0 RC1 sachant que ce n'est pas encore une version stable
certes, mais candidate à le devenir quand meme... et les derniers bugs se corrigent petit à petit donc en suivant la branche SVN le temps du developpement, tu ne prends pas de grands risques
et que des modifs risquent de me freiner
(hypothèse) dans mon travail ou devrais-je mieux me lancer sur la dernière version stable 1.9.2 pour concevoir mon nouveau site, sachant que les ressources documentaires et en contributions sont bien plus nombreuses à l'heure actuelle ?
c'est surtout les plugins que tu veux utiliser qu'il faut regarder.
certains mettrons quelques mois à avoir une version compatible spip 2 (d'autres ne sont que compatible spip 2...)
@++
Selon Bruno mercier <b.mercier@laposte.net>:
Ben voilà, tout est dans le titre. Je m'interroge. Est-il judicieux de
démarrer un site sous SPIP 2.0 RC1 sachant que ce n'est pas encore une
version stable et que des modifs risquent de me freiner (hypothèse) dans
mon travail ou devrais-je mieux me lancer sur la dernière version stable
1.9.2 pour concevoir mon nouveau site, sachant que les ressources
documentaires et en contributions sont bien plus nombreuses à l'heure
actuelle ?
Mon avis à moi que j'ai : en règle générale, on peut travailler en prod avec la
version de dev, du moment que l'on respecte certaines règles (pas de php dans
les squelettes, que du SPIP - au besoin demander ici comment transcoder du PHP
en langage SPIP; regarder quels fichiers ont été effacés de la distribution
utilisée, et effacer lesdits fichiers du site avant le transfert FTP). Les
développeurs du core sont en effet de plus en plus habiles et évitent de coller
des points noirs vraiment bloquant; j'utilise la version de dev depuis deux ans
sur des sites en prod, et je n'ai jamais eu de problème bloquant dans la durée
(en général un bug bloquant est toujours rapidement corrigé quand il est bien
diagnostiqué par le testeur).
Ceci étant, c'est une expérience personnelle, et je crois que le conseil est de
ne pas prendre de version non définie comme stable si tu sens que tu vas
paniquer à l'apparition d'un message d'erreur (généralement, je n'ai eu
quasiement que des double définitions de fonction à cause d'un fichier non
effacé, et maintenant j'efface les fichiers obsolètes avant le transfert FTP) ou
d'une page blanche (en vidant le cache ou en rechargeant à nouveau la dernière
distribution, ça remarche à tous les coups). Je prends ces symptomes avec zen et
j'essaye de trouver ce qui déconne : c'est jamais bien long (effacement de
fichiers, retrait du PHP dans les squelettes, désactivation d'un plugin, vidage
du cache, signalement du bug sur la liste des développeurs).
Mais comme je dis toujours aux utilisateurs/trices : si vous ne savez pas ce que
vous faites, ne le faite pas, et chercher à savoir comment le faire plutôt.
Voilà.
Question bête : on peut utiliser SVN pour mettre à jour un spip déjà
hébergé en distant ? ou bien cela est-il réservé à une versiopn
disponible en local sur sa propre machine ?
(oui question b ête j'avais prévenu mais SVN et moi... 
)
Etienne.
On 27 nov, 11:26, franck.du...@free.fr wrote:
Selon Bruno mercier <b.merc...@laposte.net>:
> Ben voilà, tout est dans le titre. Je m'interroge. Est-il judicieux de
> démarrer un site sous SPIP 2.0 RC1 sachant que ce n'est pas encore une
> version stable et que des modifs risquent de me freiner (hypothèse) dans
> mon travail ou devrais-je mieux me lancer sur la dernière version stable
> 1.9.2 pour concevoir mon nouveau site, sachant que les ressources
> documentaires et en contributions sont bien plus nombreuses à l'heure
> actuelle ?Mon avis à moi que j'ai : en règle générale, on peut travailler en prod avec la
version de dev, du moment que l'on respecte certaines règles (pas de php dans
les squelettes, que du SPIP - au besoin demander ici comment transcoder du PHP
en langage SPIP; regarder quels fichiers ont été effacés de la distribution
utilisée, et effacer lesdits fichiers du site avant le transfert FTP). Les
développeurs du core sont en effet de plus en plus habiles et évitent de coller
des points noirs vraiment bloquant; j'utilise la version de dev depuis deux ans
sur des sites en prod, et je n'ai jamais eu de problème bloquant dans la durée
(en général un bug bloquant est toujours rapidement corrigé quand il est bien
diagnostiqué par le testeur).Ceci étant, c'est une expérience personnelle, et je crois que le conseil est de
ne pas prendre de version non définie comme stable si tu sens que tu vas
paniquer à l'apparition d'un message d'erreur (généralement, je n'ai eu
quasiement que des double définitions de fonction à cause d'un fichier non
effacé, et maintenant j'efface les fichiers obsolètes avant le transfert FTP) ou
d'une page blanche (en vidant le cache ou en rechargeant à nouveau la dernière
distribution, ça remarche à tous les coups). Je prends ces symptomes avec zen et
j'essaye de trouver ce qui déconne : c'est jamais bien long (effacement de
fichiers, retrait du PHP dans les squelettes, désactivation d'un plugin, vidage
du cache, signalement du bug sur la liste des développeurs).Mais comme je dis toujours aux utilisateurs/trices : si vous ne savez pas ce que
vous faites, ne le faite pas, et chercher à savoir comment le faire plutôt.Voilà.
_______________________________________________
liste spip
s...@rezo.net - désabonnement : spip-...@rezo.netInfos et archives :http://listes.rezo.net/mailman/listinfo/spip
Documentation de SPIP :http://www.spip.net/
irc://irc.freenode.net/spip ouhttp://embed.mibbit.com/?server=irc.freenode.net&channel=%23spip
Loiseau2nuit (Zzz. dans un passé lointain...) a écrit :
Question bête : on peut utiliser SVN pour mettre à jour un spip déjà
hébergé en distant ? ou bien cela est-il réservé à une versiopn
disponible en local sur sa propre machine ?(oui question b ête j'avais prévenu mais SVN et moi...
Bonjour,
on peut, mais faut que le protocole svn soit installe sur l hebergement, par contre, je pense que c est pas une bonne idee, en svn on se retrouve avec un tas de fichiers propres a svn qui double le poids total du site, je sais pas si c est tres prudent au niveau de la sécurité non plus... Vaut mieux faire un "export" depuis son depot svn local, ou utiliser un machin genre rsync pour synchroniser local et distant (mais c est pas particulierement festif a mettre en oeuvre...)
triton
* Loiseau2nuit (Zzz. dans un passé lointain...) tapuscrivait, le 28/11/2008 12:19:
Question bête : on peut utiliser SVN pour mettre à jour un spip déjà
hébergé en distant ? ou bien cela est-il réservé à une versiopn
disponible en local sur sa propre machine ?(oui question b ête j'avais prévenu mais SVN et moi...
SVN = SubVersion est un outil de gestion de source décentralisé.
Comme outil, c'est un programme qui s'exécute et produit un résultat.
Donc, en local, il faut un client SVN.
Sous Windows, c'est TortoiseSVN qui marche le mieux.
En distant, il faut avoir le moyen d'exécuter la commande 'svn up' (après bien sûr avoir fait une installation avec 'svn co svn://urldusource')
En pratique, il faut donc :
- disposer d'un accès SSH (WinSCP est idéal sous Windows)
- que subversion soit installé sur le serveur (sous Debian/ubuntu : sudo apt-get install subversion')
- que ton accès SSH t'autorise à lancer la commande svn
--
RealET
On 28 nov, 11:56, triton <tri...@pointcentral.net> wrote:
Vaut mieux faire un "export" depuis son depot svn local, ou utiliser un
machin genre rsync pour synchroniser local et distant
Bon ca va m'obliger à revoir ma manière de bosser mais après tout
pourquoi pas.
Je suis sous Ubuntu et apparament ce n'est pas la doc qui manque sur
RSync.
(mais c est pas
particulierement festif a mettre en oeuvre...)
<Troll Pubicitaire ON>
"T'inquiètes pas pour ça, toi, moi j'aime ça jouer aux cartes !!!"
</troll publicitaire OFF>
Merci pour la réponse 
Etienne.
triton
_______________________________________________
liste spip
s...@rezo.net - désabonnement : spip-...@rezo.netInfos et archives :http://listes.rezo.net/mailman/listinfo/spip
Documentation de SPIP :http://www.spip.net/
irc://irc.freenode.net/spip ouhttp://embed.mibbit.com/?server=irc.freenode.net&channel=%23spip
Loiseau2nuit (Zzz. dans un passé lointain...) a écrit :
On 28 nov, 11:56, triton <tri...@pointcentral.net> wrote:
Vaut mieux faire un "export" depuis son depot svn local, ou utiliser un
machin genre rsync pour synchroniser local et distant
Bon ca va m'obliger à revoir ma manière de bosser mais après tout
pourquoi pas.
Je suis sous Ubuntu et apparament ce n'est pas la doc qui manque sur
RSync.(mais c est pas
particulierement festif a mettre en oeuvre...)
<Troll Pubicitaire ON>
"T'inquiètes pas pour ça, toi, moi j'aime ça jouer aux cartes !!!"
</troll publicitaire OFF>
Quand je dis pas festif, je fais pas ma begueule...
il faut de toute maniere que le protocle rsync soit installe sur le serveur de prod...
j ai passe un temps infini a mettre en place une solution utilisant :
capistrano - ssh - svn - rsync pour synchroniser dans les deux sens les sites en local et en prod (et sauvegarde automatique des bdd distantes et restauration local...)
Si tu veux les differents scripts tu demandes... par contre, j ai pas le niveau pour faire un tutorial complet la dessus...
triton
j ai passe un temps infini a mettre en place une solution utilisant :
capistrano - ssh - svn - rsync pour synchroniser dans les deux sens les
sites en local et en prod (et sauvegarde automatique des bdd distantes
et restauration local...)
Si tu veux les differents scripts tu demandes... par contre, j ai pas le
niveau pour faire un tutorial complet la dessus...
Sinon pour faire tout ça, je recommande Unison,
http://www.cis.upenn.edu/~bcpierce/unison/
Il a l'avantage sur rsync de garder des infos sur l'état de
l'arborescence (donc de voir de quel côté les trucs ont changé), de
faire la synchro dans les deux sens, et d'avoir une configuration facile
(on lui dit dans l'interface d'ignorer un type de fichier ou un
répertoire et il s'en souvient).
Inconvénient, ce n'est pas super standard, et il faut qu'il soit
installé à l'autre bout.
/v
--
Vincent Beffara
UMPA - ENS-Lyon
46 allée d'Italie
69364 Lyon Cedex 07
Tél : 04 72 72 85 25