En tant qu'auteur de nano-projets, je te conseillerais de rester le plus simple possible. Pour mon premier, j'avais vu "grand" avec un site dédié (présentation, changelog, FAQ, page de téléchargement, le tout en HTML vaguement mouliné), branches stable/devel et listes de diffusion devel/annonces. Ça n'a jamais servi à rien, à part à alourdir la gestion du bouzin. C'est pour ça que très vite j'ai adopté le modèle "un projet, une branche, une page, (jawohl!)" et ai par la suite fini par grouper tous mes projets sur un seul site (au passage, merci à l'équipe de tuxfam. pour avoir toléré mes tergiversations :). J'ai même au bout du compte abandonné les contrôleurs de version. En cinq ans, je ne me souviens effet pas avoir eu besoin de revenir en arrière. D'ailleurs, même si ça se présentait, en tant qu'auteur unique je ne vois pas ce qui serait insurmontable (de fait, tout reste dans mes compétences, en plus hein! ça me fait la couenne, j'ai qu'à savoir ce que je veux), et puis il y a toujours le rustique mais efficace cpold.
Aujourd'hui je génère mon site et mes manuels à partir d'une moulinette perso qui prend des sources type Markdown (jette un œil sur l'implémentation initiale de cette syntaxe, tu verras que ce n'est pas très sorcier de bricoler quelque chose autour, y compris vers groff_man, qui est finalement assez simple). Je pousse ensuite tout ça en statique via un script de miroir basé sur lftp, et roule (autre chose appréciable chez tuxfam., tu peux gérer ton site alapapa®).
D'une manière générale, attends que les besoins soient là avant d'y répondre, tout anticiper étant le meilleur moyen de se retrouver avec une montagne accouchant d'une souris (ou plutôt l'inverse : un truc long et douloureux qui fait bien chier). Fais donc avant tout les choses pour toi, au plus simple comme ça t'arrange, et reste à l'écoute des éventuels retours pour décider des changements à apporter.
J'y travaille actuellement pour mon projet, et je m'aperçois que les enjeux sont importants, car une fois le logiciel publié, la liberté de modification sera limitée par l'exigence de rétro-compatibilité.
Sauf que l'ampleur des changements, tu ne peux jamais la prévoir. Pour le moment, j'ai trouvé deux parades :
publier un ChangeLog circonstancié, sur le modèle de ce que fait Patrick Volkerding pour Slackware. Ça permet de donner les infos de mises à niveau et d'indiquer les motivations de tel ou tel changement.
attribuer ce que j'appelle une "version totémique", qui assure la compatibilité entre les données de l'utilisateur et la version du logiciel. Par exemple pour tofu, le format de la todo est nommé "Ciboulette". Si jamais je suis amené à changer quoi que ce soit, j'aurais juste à changer ce nom pour que tofu réclame sans rien péter la mise à niveau (j'ai fait la commande dédié tofuup, mais on peut aussi faire des scripts dédiés, si on veut être moins formel). Ainsi, je peux continuer à faire ce que je veux avec un désagrément minimal pour les utilisateurs et en restant totalement libre au niveau du numéro de version (un changement de totem n'est pas forcément synonyme d'un gros changement interne ou d'interface).
Voilà, c'était mon petit retour d'expérience à deux balles… :)
# Keep it...
Posté par Ignatz Ledebur . En réponse au journal Publication de petits projets. Évalué à 6.
En tant qu'auteur de nano-projets, je te conseillerais de rester le plus simple possible. Pour mon premier, j'avais vu "grand" avec un site dédié (présentation, changelog, FAQ, page de téléchargement, le tout en HTML vaguement mouliné), branches stable/devel et listes de diffusion devel/annonces. Ça n'a jamais servi à rien, à part à alourdir la gestion du bouzin. C'est pour ça que très vite j'ai adopté le modèle "un projet, une branche, une page, (jawohl!)" et ai par la suite fini par grouper tous mes projets sur un seul site (au passage, merci à l'équipe de tuxfam. pour avoir toléré mes tergiversations :). J'ai même au bout du compte abandonné les contrôleurs de version. En cinq ans, je ne me souviens effet pas avoir eu besoin de revenir en arrière. D'ailleurs, même si ça se présentait, en tant qu'auteur unique je ne vois pas ce qui serait insurmontable (de fait, tout reste dans mes compétences, en plus hein! ça me fait la couenne, j'ai qu'à savoir ce que je veux), et puis il y a toujours le rustique mais efficace cpold.
Aujourd'hui je génère mon site et mes manuels à partir d'une moulinette perso qui prend des sources type Markdown (jette un œil sur l'implémentation initiale de cette syntaxe, tu verras que ce n'est pas très sorcier de bricoler quelque chose autour, y compris vers groff_man, qui est finalement assez simple). Je pousse ensuite tout ça en statique via un script de miroir basé sur lftp, et roule (autre chose appréciable chez tuxfam., tu peux gérer ton site alapapa®).
D'une manière générale, attends que les besoins soient là avant d'y répondre, tout anticiper étant le meilleur moyen de se retrouver avec une montagne accouchant d'une souris (ou plutôt l'inverse : un truc long et douloureux qui fait bien chier). Fais donc avant tout les choses pour toi, au plus simple comme ça t'arrange, et reste à l'écoute des éventuels retours pour décider des changements à apporter.
Sauf que l'ampleur des changements, tu ne peux jamais la prévoir. Pour le moment, j'ai trouvé deux parades :
Voilà, c'était mon petit retour d'expérience à deux balles… :)