Nouvelles versions et mode de distribution

Besoins

I. Philosophie de WikiNi : léger, simple, tout terrain, rapide

Il me semble important de pouvoir conserver un noyau de base qui fait que WikiNi garde ses qualités intrinsèques, à savoir :

• facilité d'installation,
• rapidité d'installation,
• rapidité d'exécution,
• fonctionnement avec une majeure partie des fournisseurs d'accès,
• simplicité d'utilisation.

II. L'ouverture vers un moteur plus riche

Il me semble également important de pouvoir intégrer au projet WikiNi toutes nouvelles contributions, cette intégration ne devant pas se faire au détriment des qualités sus-citées.
Je propose à partir de cette base, de réfléchir à un nouveau mode de distribution de WikiNi.

-- DavidDelon

Solution provisoire

Tant que WikiNi reste d'un poids raisonnable (environ 600 Ko non compressé, soit environ 3 minutes de téléchargement pour un modem 56Kbit/s), il sera livré sous la forme :

• d'un logiciel monobloc
• augmenté de "contribs" publiées sur wikini.net.

Cette solution reste valable tant que WikiNi n'augmente pas fortement de poids et tant qu'une autre solution n'est pas mise en oeuvre.

---

Premières pistes de reflexion

• Définir les fonctionnalités minimum.
• Définir le type de découpage à mettre en place : Regarder Spip et Spip-contrib par exemple, ou des systèmes intégrants une gestion de plugins comme phpgroupware. Prévoir des procédures d'intégration dans le noyau de WikiNi des fonctionnalités les plus utilisés.
• Améliorer les procédures d'installation : installation à la templeet ? Autres méthodes ?

-- DavidDelon

Je serais plutôt d'accord avec l'option WikiNi et WikiNi-contrib. --GarfieldFr

Oui pour tout David, notamment en étudiant de près les procédures d'intégration dans le noyau de WikiNi des fonctionnalités les plus utilisées.
J'ajouterai, qui me paraît fondamental : améliorer nos procédures de publication d'une nouvelle version. C'est vrai que la dernière version stable 0.1.3 ne reflète pas du tout les progrès de WikiNi. Personnellement, je n'ai jamais rien compris aux mystères des variables de configuration wakka_version et wikini_version... notamment, pourquoi deux variables ? ne peut-on simplifier tout ça ? [Tiens, bonne remarque ça... :) -- ProgFou] et qu'est-ce qui nous empêche actuellement de passer 0.4.1 en stable ? [Plus rien ? ;-) -- ProgFou] -- CharlesNepote

Un accord sur la proposition de découpage. Je ne pense pas qu'il soit judicieux de distribuer Wikini, sans une distribution de base, expurgée de la doc. -- DavidDelon

• Mhhh... $ du -sk wikini => 620 Ko, non compressé ! Pour ma part je pense que c'est franchement raisonnable et que le découpage n'est pas urgent : ça pourrait attendre la version 0.5, non ? -- ProgFou, qui veut cimenter la base avant de continuer de poser des briques... :)

Le projet WakkaFr, qui est devenu Wikini, est né de la volonté de disposer d'un outil léger, facile à installer, chez la majorité des hébergeurs acceptant php/mysql. Phpwiki existait et dans ses premières versions, répondait à ces critères, malheureusement la dernière version disponible, était difficile à installer et à paramétrer pour un débutant, fonctionnait difficilement chez tous les hebergeurs, j'ai trouvé Wakka que j'ai commencé à adapter : avec cette idée en tête, ne jamais se retrouver avec une uzine à gaz difficille à installer, avoir toujours la possibilité d'installer les fonctionnalités miminum. Je ne vois pas pourquoi il ne serait pas possible d'installer un Wikini sans la documentation, sans des actions qui sont certes utiles mais d'un usage anedoctique pour un débutant (coloration syntaxique par exemple (rien de personnel GardfieldFr? ;-) !). En fait, on peut dire que, pour moi, c'est cet article : http://webgeneraction.levillage.org/article.php3?id_article=182 de Walk (un des premiers participants à WakkaFr !) qui a été le moteur de mon investissement dans un projet tel que WikiNi. -- DavidDelon

Ok. Donc si je comprends bien ta réponse subtile à ma question : tu souhaites qu'on fasse le tri avant la sortie de la version 0.4.1, c'est bien ça ? Pas de problème de mon coté : je ne suis pas dans l'urgence. Je pousse juste un peu histoire d'arriver un jour à se décider à sortir une version stable. ;-) -- ProgFou

On peut très bien distribuer une version allégée et une version complète non ? Si on ne peut pas se mettre d'accord sur les actions à retirer on peut, il me semble, au moins proposer une version sans la documentation : à quoi sert elle quand on veut installer un WikiNi rapidement comme espace de travail (style tableau blanc), dans un coin du web ? -- DavidDelon

• Tout à fait, pas la peine d'en discuter plus longtemps (en ce qui me concerne) : je n'ai aucune objection particulière sur le sujet (ma proposition d'attendre la 0.5 était surtout une demande d'avis/confirmation/infirmation) et je suivrai donc la position du leader ! ;-) Donc au boulo ! Je vais relire cette page tranquillement et voir si je peux compléter les propositions déjà faites. -- ProgFou

---

Proposition de découpage

En attendant que le projet packageur/installateur mûrisse un peu plus (j'ai pas dit "pourrisse" :))), il est facile de packager des Wikini selon quelques critères simple :

Un wikini de base : wikini-0.4.1-base.tar.gz contenant au 11/03/2004 les fichiers suivants :



Un wikini avancé (complet ? ...) wikini-0.4.1-complet.tar.gz contenant au 11/03/2004 les fichiers suivants :



Soit le même qu'au dessus, avec en plus quelques morceaux de doc faisant 180Ko qui n'en font que 7 de moins a télécharger
une fois tgz-isé. Est-ce que ça vaut vraiment la peine de s'embéter pour ça ?
En plus, ces .txt pourraient dégager une fois l'install terminée puisqu'ils ne servent plus à rien une fois qu'ils sont en base.
Au pire, on pourrait proposer de ne pas les installer si c'est l'espace mysql qui est limité. -- PiiF

Des wikini contrib

Des wikini localisés (?)

wikini-0.4.1-base-de.tar.gz
wikini-0.4.1-base-en.tar.gz
wikini-0.4.1-complet-en.tar.gz
etc ...

-- DavidDelon

• Distribution basique / Distribution complète :
  • C'est quoi la différence entre la distribution basique et la distribution complète ? Elle porte uniquement sur les pages installées par défaut ? -- CharlesNepote
    • Oui, dans cette proposition , mais on peut imaginer de plus grandes différences : un minimum d'action dans le wikini de base et toutes les actions dans le wikini complet. -- DavidDelon
• A propos des WikiNi-contrib :
  • Je ne suis pas partisan de WikiNi-contrib si les contributions ne sont pas modulaires et obligent à modifier les fichiers existant de la distribution classique. -- CharlesNepote
    • Entièrement d'accord, l'idée etait plutôt : wikini base : le minimum, wikini-complet : la distribution complète (tout le cvs) , wikini-contrib : wikini-complet + contributions modulaires (il reste à definir un espace pour déposer les contributions). -- DavidDelon
  • Ne suffit-il pas de laisser les contributions en téléchargement ?
    • Pourquoi pas -- DavidDelon

• A propos des WikiNi localisés : je pense qu'on est pas encore pressé et je préfère voir maturer les propositions qui se font jour actuellement. -- CharlesNepote
  • Ok -- DaviDelon?
  • Il y aurait quoi dedans ? les pages de setup/doc ou il faut également penser tout un atirail de localisation des messages ? Dans le second cas, ça fait un sacré boulot pour un résultat généralement assez lourd à manipuler -- PiiF

---

Processus d'installation

Pour le processus d'installation, je ne vois pas ce que tu lui reproche, il me semble très clair et simple d'utilisation. Quand tu vois le processus d'installlation de produit comme PHPNuke, WikiNi est très simple à installer. --GarfieldFr

Oui il est clair, mais il peut être amelioré, par exemple il peut y avoir, comme avec spip, un mécanisme de détection automatique des bases de données présentes. D'autre part, la multiplication récente du nombre de fichier de la distribution, suite à l'ajout de la documentation (ce n'est pas un reproche GarfieldFr !), rend l'installation sur un serveur relativement longue, sur free par exemple, même avec de l'ADSL 1024/128. D'autres solutions peuvent être étudiées : je pensai à l'installation automatique que propose spip http://www.spip.net/spip-dev/INSTALL/ ou a une procédure de packetage à la templeet : http://www.templeet.org/download.fr.html .

-- DavidDelon

• Je comprend pas la remarque sur la doc, tu veux dire que l'upload est long en FTP ? --GarfieldFr
• Oui, en fait plus long qu'avant, puisqu'il y a négociation d'une 30aine de transferts supplémentaires -- DavidDelon
• Oui, en effet, mais je peux te dire que la quantité et la taille des fichiers est toute petite par rapport à certain autres outils comme PHPNuke et autre CMS. Je crois pas que le volume de données à faire transiter par FTP soit un critère important. Le seul cas ou cela peut être penible, c'est lorsque on utilise un WebFTP? --GarfieldFr
• Dans l'absolu, plus le transfert est rapide, mieux c'est, pour moi c'est important, j'aimerais que Wikini soit installable rapidement depuis un modem 56k (voire moins). -- DavidDelon
• Je comprend, la meilleure solution serait une installation à la Spip, juste un seul script à télécharger qui va chercher les fichiers nécéssaire sur le site WikiNi. Avec ce type d'installation, le fichier à télécharger ne devrait pas faire plus de quelques Ko ce qui est facile à charger même en 56K. Je trouve d'ailleur cette solution assez séduisante, je vais voir ce que je peux faire ... --GarfieldFr

Je suis de l'avis de David sur l'installation. Cela fait un moment que nous avons évoqué la facilité d'installation. Je voudrais également proposer de développer une solution d'installation de wikini 'séparée', c'est à dire qu'on la ferait de bout en bout. Cela nous permettrait de mettre ce nouveau code en licence GNU GPL. -- PatrickPaul

L'installation type Spip avec un seul fichier qui récupère tous ce qu'il faut depuis le site principal est en effet très séduisante mais :

• Il ne faut pas que l'hébergeur soit en mode "safe_mode" de PHP sinon il y aura des problèmes pour créer l'arborescence des répertoires et y copier les fichiers. (cas de Free par exemple, ou alors je sais pas comment faire...)
• Il faudra que le site de référence soit rapide car il y a une limite de temp à l'exécution d'un script, ou alors il faudra fragmenter les téléchargements en plusieurs parties. Mais c'est faisable.
• Nécessite une connexion à internet si on veut installer WikiNi dans un réseau local. Ou alors il faut passer par l'installation "à la main" comme aujoud'hui.

Par contre, l'avantage est d'avoir la dernière version de WikiNi, ce qui est plutôt bien. En plus, ce processus permet d'installer que les handlers/actions nécessaire et pas tous ceux présent. --GarfieldFr


Oui, je verrais bien un truc comme cela : (Ca pourrait même être un projet d'installateur web php, indépendant de Wikini, l'équivalent des installateurs que l'on peut trouver pour Windows ou autre).

Procédure d'installation (à revoir ...)

• Selection du type de paquetage à récupérer, choix multiples possible : (cf http://www.templeet.org/download.fr.html )
  • Core
  • Documentation
  • Contrib A
  • Contrib B
  • ...
• Installation des sources
  • 1. Download du tar.gz généré en fonction des selections ci-dessus, puis installation classique ou bien :
  • 2. Download d'une amorce à installer chez l'herbergeur, puis installation par internet
    • Je verais plutôt cette procédure d'installation car la précédente apporte assez peu de chose à mon avis. --GarfieldFr
• Configuration
  • Detection du type d'installation
    • Nouvelle installation
    • Mise à jour (dans ce cas récupération des parametres utilisateurs).
  • Saisie des parametres utilisateurs (si besoin est)
  • Détection de l'environnement (bases de données disponibles, droits d'écriture, spécifique fournisseur (?))
  • ...

-- DavidDelon

Les perspectives que vous évoquez sont vraiment très intéressantes ! Personnellement, je rêve d'une installation à la Templeet, à condition qu'elle fonctionne n'importe où (intranet et local compris)... J'ai cependant un peu peur du temps que cela va prendre... je pense en effet que cela devrait être un projet à part entière qui ne devrait pas géner le développement de WikiNi. Peut-être serait-il intéressant que vous contactiez les développeurs de Templeet pour leur proposer la naissance d'un tel projet ?
Pour l'installation des sources, la solution 1 me paraît intéressante pour celui qui ne veut qu'examiner les sources.
-- CharlesNepote

Oui ce projet est un "must" que nous devrions réaliser. Comme dit CharlesNepote, et dans l'esprit du commentaire que j'ai fait plus haut, je pense qu'il faut en effet faire ce projet indépendemment. Je rappelle que cela permettrait de mettre le code en GNU GPL.
-- PatrickPaul

Une autre idée que je n'ai à priori pas vue ici serait de permettre l'installation avec la commande pear (voir http://pear.php.net/manual/fr/installation.cli.php [fr]).
Ainsi, il suffirait de faire en ligne de commande
pear install http://www.wikini.net/wikini-last.tgz
pour avoir la dernière version de Wikini installée, avec éventuellement les packages nécessaires. Ces packages pourraient être des packages optionnels fournis eux-aussi sur le site de Wikini, ou des packages PEAR de base utilisés par Wikini, comme par exemple le nouveau package Text_Wiki (voir http://pear.php.net/package/Text_Wiki [en]) quand il sera stabilisé.
-- NicolasHoizey

Est-ce que ça marche également autrement qu'en ligne de commande ? Est-ce qu'on peut utiliser ça chez free, ovh ou l'autre.net ? -- PiiF

• Bon, j'viens de me battre pour installer pear : c'est après avoir downloadé la moitié du bousin qu'il annonce gaiement qu'il me manque une extension dans php.
• De plus, chez pear, que pour beaucoup d'hébergeurs, c'est le bordel à installer.
• Bref, ça me parait mal barré. -- PiiF

---

Gestion des contributions

Une première approche pragmatique est de centraliser les contributions dans une page ContributionWikini et de proposer un format de documentation. (Voir Jedit : http://community.jedit.org/cgi-bin/TWiki/view/Plugins/WebHome [en] , Jedit est un editeur en Java multi-language (php, c, java etc.) avec coloration syntaxique et plein de plugins : navigateur code, gestion de projet, cvs, ftp, editeur xml ...).

Est-ce qu'il a déjà été question du principe des MOD de phpBb ici ? (je me souviens en avoir parlé, mais je sais plus si c'était ici ou chez spip :-) Ça permettrait de faire une distrib minimale puis de proposer l'installation de différents éléments après coup, via une interface réservée aux administrateurs. -- PiiF

---

Intégration d'autres fonctionnalités dans le noyau

C'est une question que je me pose depuis quelques temps. Est-il possible d'intégrer facilement des fonctionnalités au noyau ? Comment ? Je pense notamment à des classes PHP permettant de gérer flux RSS, des interfaces avec Jabber, mon wikini sémantique, etc.
J'ai fait des tests avec des includes etc. mais qui n'ont pas été concluants.
-- CharlesNepote

Moi je vois une solution qui demanderai un gros travail de préparation : une réécriture du noyau. Mais je pense qu'il faudrait vraiment faire un cahier des charges bien complet, puis une analyse fonctionelle et enfin passer à la pratique lorsque tout ça aura bien murit.
-- PatrickPaul

---

Publication semi-automatisée des versions de WikiNi sur wikini.net

Il me paraît intéressant de pouvoir fournir des versions à jour de WikiNi sur wikini.net :

• fichiers tar.gz et zip (pour les utilisateurs de windows) de la dernière version stable : par exemple wikini-0.4.1.tar.gz et wikini-0.4.1.zip
• fichiers tar.gz et zip de la dernière version stable patchée d'éventuels backports : par exemple wikini-0.4.2.tar.gz et wikini-0.4.2.zip
• fichiers tar.gz et zip de la dernière version du CVS : par exemple wikini-0.5.dev-20040623.tar.gz et wikini-0.5.dev-20040623.tar.gz

La création et la publication de ces fichiers doit pouvoir être automatisée facilement. J'ai créé un petit script shell permettant sous Linux de réaliser les archives à partir du CVS. Ce script est largement perfectible et je compte sur les gourous Unix parmis nous pour l'améliorer :



J'ai cependant quelques problèmes :

• je ne sais pas comment récupérer le CVS sans les informations de CVS (les répartoire /CVS dans chaque répertoire ; faut-il les exclure au moment de la compression ?)
  • utiliser cvs export au lieu de cvs co
• je ne sais pas comment récupérer le CVS des branches
  • cvs export -r nomDeBranche repertoireRacine
• je ne sais pas comment insérer la date du jour dans le nom des fichiers
• je galère un peu pour trouver la bonne commande FTP
  • ftp -n site < < EOF
  • user login motDePasse
  • cd ...
  • put ...
  • EOF
    • Ok. Merci PiIf, je vais tester ça. -- CharlesNepote

L'idéal serait de placer ce(s) script(s) dans le cron d'une machine connectée 24/24 d'un admin complaisant...
Qu'en pensez-vous ?
-- CharlesNepote

• gna.org a prévu de le faire vient de le faire : https://gna.org/support/index.php?func=detailitem&item_id=168

# date format YYYYMMDDHHmmss
TIME_STAMP=`date +"%Y%m%d%H%M""%S"`

tar zcvf wikini_${TIME_STAMP}.tar.gz ` find wikini|grep -v "CVS"`

https://gna.org/support/index.php?func=detailitem&item_id=264
sftp cnepote@download.cvs.gna.org/upload/wikini << EOF
put wikini_${TIME_STAMP}.tar.gz
EOF
il te faut une clé SSH valide / opérationnelle
-- BenoitAudouard 20040624

Merci BenoitAudouard pour le coup du ${TIME_STAMP}, je vais tester ça. Petite remarque, je souhaite uploader mon fichier sur wikini.net et non sur gna.org (le code donné par PiIf ci-dessus devrait aller en y ajoutant ton time_stamp). Par ailleurs, je ne comprends pas bien la fonctionnalité mise en place sur gna.org. La page que tu mets en référence est illisible pour un néophyte... le lien http://cvs.gna.org/daily/wikini.tar.gz (j'ai cru comprendre qu'il s'agissait de cela) ne donne toujours pas de bons résultats. Au final, je préfère faire la manip moi même car je veux aussi le fichier en .zip pour malheureux utilisateurs de windows... -- CharlesNepote

• oula moi et mes [non] qualités didactiques ;-) Je faisais référence à la demande d'évolution que j'avais faite et qui correspond à ton besoin. yeupou a répondu et t'oriente dans sa réponse vers la page Dayly tarballs c'est http://cvs.gna.org/daily/wikini-snapshot.tar.gz qui devrait être le bon lien (dès qu'ils commenceront à être créé, dommage il n'y a pas de date...) il est aussi possible de le récupérer par wget (ce sera plus simple...) -- BenoitAudouard
• Apparement c'est fonctionnel, mais l'archive contient toujours un répertoire CVSROOT... -- ProgFou 20040924

---

Discussion

• (au sujet de la detection de l'environnement) j'aimerais bien savoir comment tu compte faire ça !? On peut certe avoir la liste des base MySQL existante, mais il faut déjà avoir entré le nom du serveur et ensuite le login du compte MySQL. Une fois que tu as ça, alors seulement tu peux détecter les bases disponible. --GarfieldFr [Oui, tu as raison ! Je suis allé un peu vite là ... -- DavidDelon ]
  • Dans Spip, il y a une première phase bdd, login , mot de passe, et de là, ça propose le créer une base où d'en prendre une existante. -- PiiF

• (au sujet du type d'installation : tar.gz classique ou amorce ) Je verais plutôt cette procédure d'installation (amorce) car la précédente apporte assez peu de chose à mon avis. --GarfieldFr Il faut quand même garder l'installation standard non ? Car le système d'amorce risque de ne pas fonctionner dans toutes les situations et necessite d'être connecté à Internet pour l'installation (comme tu l'as fait remarqué). -- DavidDelon Oui, bien sur qu'il faut garder l'installation normale, mais comme elle est actuellement, pas en générant une archive uniquement avec ce que l'utilisateur désire. Ou plutôt plusieurs archive, une archive avec le noyau et une archive avec des contributions --GarfieldFr

Pour les amateurs de l'auto installation, on peut regarder du côté de PhpZip? : http://www.phpconcept.net/phpzip/index.php. La doc mentionne :
"En mode auto-extraction le fichier d'auto-start, s'il est présent, est automatiquement lancé. Cela correspond à un embryon d'application d'installation."
-- CharlesNepote

Dans spip, l'auto-installeur est effectivement un outil épatant, mais c'est surtout une usine à gaz très difficile à maintenir en fonction des différents cas d'hébergeurs (droits à la con, possibilité de download, disponibilité de certaines fonctions ...). Ça me parait donc très chaud à faire, à moins de ressortir l'historique de ce produit et d'en faire un produit indépendant. (je ne suis pas volontaire pour me lancer la dedans :-) -- PiiF

Un peu plus haut, j'ai évoqué les MOD de chez phpBB. L'idée serait la suivante :

• une distrib minimale (le wikini-0.4.1-base.tar.gz évoqué plus haut, voir moins) en tgz ou avec un installeur "simple"
• dans cette base, un gestionnaire de MODs (à bricoler à partir de celui de phpBB (déjà fait pour spip, donc surement pas insurmontable))
• des options standards sous forme de MODs (la doc, quelques actions assez spécifiques comme trail, redirect ou diaporama, ...)
• des contribs sous forme d'autres MODS (action attach, spikini, traductions ...)

L'intéret majeur, c'est une simplicité d'installation (y compris pour d'éventuelles interventions en bdd), des mods immédiats pour les contribs de type action ou handler, et une certaine indépendance de la version (un MOD étant plus souple qu'un patch).
La difficulté, c'est l'upgrade : soit on réinstalle et on réapplique tous les MOD (mais on risque fort de paumer des morceaux), soit les upgrades doivent eux aussi être des MOD (mais c'est assez chaud à faire quand il y a des évolutions lourdes).
Personnellement, je n'ai pas d'expérience d'écriture de MOD, je suis donc peut être en train de réver debout, mais j'ai appliqué plusieurs MOD successifs assez balaises sur un phpBB sans le casser, ce qui est assez épatant. -- PiiF

Pour plus de précision voir le [en]. Sur le principe ça à l'air bien mais il faut voir la difficulté d'intégration. -- CharlesNepote

Une première version d'un utilitaire, reprenant les idées exprimées ici est disponible en test : http://www.wikini.net/contrib. Par contre les MODS étant trop spécifiques à mon goût, j'ai préféré utiliser le format diff : les outils pour le produire existant sur tous les systèmes et étant simples d'emploi; il ne manquait plus qu'un outil pour pouvoir patcher en php, j'en est écrit un en me basant sur la Libxdiff, de façon à pouvoir être indépendant de l'hebergeur sur ce point là. -- DavidDelon

Distribution monolithique ou sur mesure ?

On tergiverse et on n'arrive pas à se mettre d'accord sur quelque chose somme toute assez simple : faut-il un seul type de distribution de Wikini, ou créer des distributions sur mesures (allégées, traduites etc.) ? -- DavidDelon

• Réponse simple pour ma part (à couper/coller ailleurs) : si on se disperse trop, on n'aura pas assez d'énergie pour tout faire. Alors autant garder un système simple avec une seule distribution. -- CharlesNepote
• Idem CharlesNepote, une seule version de la distribution à maintenir me semble suffisante --GarfieldFr
• Idem, au moins jusqu'à la version 1.0, ou en tous cas pas avant qu'on commence la L10N, ÀMHA... -- ProgFou
• Idem, une seule distrib´ la modularité viendra "naturellement" avec un outil de choix des modules pour créer les types de distrib´ - plus tard :-) -- BenoitAudouard
• J'appuie également l'idée de garder une seule distribution pour le moment. -- PatrickPaul

Je m'incline devant la majorité. Je reste persuadé qu'il est important de proposer un wikini allégé. J'envisage de le faire passer en contrib, mais je crains de créer une confusion avec la distribution officielle. -- DavidDelon

---

Que doit-on intégrer dans les backports ?

J'aimerai avoir votre avis sur ce que l'on doit intégrer ou non dans les backports vers les versions précédentes de WikiNi.
Question subsidiaire : faut-il republier une version à jour immédiatement après un backport ? comment le nomme-t-on ?
Pour ma part je pense :

• intégrer uniquement les correctifs de sécurité
• publier les nouvelles versions immédiatement sous un nouveau nom : WikiNi 0.4.2 pour la prochaine version de la branche 0.4.

-- CharlesNepote

Sur la question de ce qu'on doit intégrer, mon avis est qu'il ne faut mettre que ce qui est indispensable pour un fonctionnement correct et sécurisé de WikiNi, c'est à dire les mises à jour de sécurité et les bogues ayant pour conséquence des pertes de données, rien d'autre. -- ProgFou

---

Quelle politique pour la numérotation des versions ?

Je pense qu'il faut se fixer quelques règles afin de simplifier les changements de versions.
Je propose de suivre le modèle classique majeur.mineur.bogues (ex : 0.4.1, 0.4.2, 0.5.0, ...).

• le changement de majeur correspond à un changement majeur dans le logiciel, en particulier niveau compatibilité des données avec la version précédente ou encore interface utilisateur complètement revue ;
• le changement de mineur correspond à un changement mineur dans le logiciel, par exemple des améliorations, des ajouts de fonctionnalités, des changements visibles (mais non déroutants) niveau interface ;
• le changement de bogue correspond à une correction de bogue, en particulier ceux qui ont des conséquences niveau sécurité ou pertes de données.

-- ProgFou

Oui, je rajouterai éventuellement le numéro de révision, mais bon, ce que décrit ProgFou est suffisant je pense pour l'instant ...
version MAJEUR.MINEUR.REVISION.CORRECTION
--ThierryBazzanella

Totalement d'accord avec ProgFou. C'est le système le plus simple et qui est d'ailleurs largement employé dans les logiciels libres.
-- CharlesNepote

---

Il n'y a qu'a faire 1 systeme de patchs ! avec :

• Une base (un peu comme le noyau Linux)
• Des extensions disponibles sur un site spécial

Les extensions auraient comme dossier /wikini/extensions/.
Ce serait un peu comme Actions mais dans le tableau de bord serait disponible la liste des patchs et on pourra y acceder pour les configurer, les utiliser, etc... ils seront représentés comme des fichiers de code.

J'ai aussi une autre idée. Il s'agirait d'un systeme de themes.
Cela serait beaucoup plus pratique que de changer wakka.css et les newbies s'en serviraient plus facdilement. Il faudrait aussi un générateur de theme (dans une extension ajoutable) qui permetrrait aux newbies de créer leurs propres themes facilement et ainsi de "doper" la création de themes Css pour WikiNi :-)

Voila, Aweb

---

---