Gestion des versions de documentations, avant tout

Avec l'arrivée imminente de code.spip.net, et en ayant en tête les prochains sites spécifiques possibles pour vider spip.net (rediger.spip, integrer.spip), je pense qu'il faut s'interroger de toute urgence sur la manière dont on doit gérer les changements de version lorsqu'il y a des évolutions majeures.

Cela n'a pas été vraiment prévu pour programmer.spip.net, et c'est normal vu l'énorme boulot qu'avait déjà abattu Marcimat.

Mais justement ! : au regard de cette expérience, et du fait que "programmer3" est toujours dans un état bâtard, et n'est toujours pas sur l'URL "première" alors qu'il s'agit pourtant de la version stable, et bien il faut décider d'une méthode, en *amont* de tout site de documentation.

Sinon dans un ou deux ans, on va se retrouver dans les mêmes situations, à avoir des sites difficile à bouger et à mettre à jour, voir complètement bloqués.

Je crois que ce serait pas mal d'arriver à déterminer une *même méthode* qui serait appliquée à l'ensemble des sites de doc.

Doit-on vraiment créer un nouveau site différent à chaque fois que des changements majeurs se font (X qui change, ou Y qui change avec beaucoup d'ajouts) ? Avec une URL différente en plus ? Doit-on plutôt faire un site unique, avec des liens entre les versions d'une même fonction lors qu'une même doc existe dans plusieurs version ?

Prenez la documentation (très bien faite, je trouve) de Symfony :
http://symfony.com/fr/doc/current/book/routing.html
pour tel point précis, on a la document "current" (qui est un alias de la version stable en cours "2.2") + des liens vers les versions précédentes ainsi que même la version en dev.

Parfois les documentations n'ont pas bougé et sont exactement les mêmes : peu importe. Il y a un processus de copie à chaque fois, et les versions précédentes à mon avis ne bougent plus.
Mais ce n'est pas séparé, il y a un lien entre les versions.

Voilà, qu'en pensez-vous ? Êtes-vous d'accord, autant que faire se peut, d'essayer de trouver une méthode qui convienne à toutes les docs ?

Cela permettrait de ne pas se poser de questions sur l'implémentation dès que l'on se décidera à lancer un écrémage de spip.net vers des mini-sites plus spécialisés.

(Cela vient notamment d'une réflexion récente qu'en fait, ça sera vraiment trop compliqué de modifier spip.net tant qu'on ne l'aura pas réellement vidé pour ne garder que l'aspect "portail".)

Pour être plus "todolist", je pense qu'il faut, à peu près dans l'ordre :

1) trouver une méthode pour gérer les versions, ou deux maximum si vraiment un site demande une manière de gérer différente
2) appliquer cette méthode à programmer.spip
3) sortir officiellement code.spip en ayant déjà intégré dès le démarrage cette histoire de version
4) sortir l'intégration squelettes dans un site à part, avec le système de version, et en gérant les redirections (cf référencement et liens pointant sur spip.net)
5) même opération pour la doc de rédaction et d'administration (d'ailleurs "editer.spip" serait peut-être mieux comme nom pour ne pas parler que de rédaction)
6) enfin refondre le portail, ne contenant plus que la description générale, la liste des versions, et plein de jolies pages redirigeant aux bons endroits suivant les profils (user, dev, graphiste, etc)

Go ? Une groupe de travail pour réfléchir *spécifiquement* au problème du versionning de documentation ?

--
Vincent

--
RastaPopoulos