Gestion de projet
Un article de Prog.
Sommaire |
Hébergeur de projet libre
Il existe de nombreux hébergeurs de projets libres :
- gna.org
- berlios.de
- Savannah (GNU)
Certains sont dédiés à un langage de programmation :
- Python Package Index : dépôt de tarballs avec une page de descriptif
- CPAN (Comprehensive Perl Archive Network)
- JSAN (JavaScript Archive Network)
Avec une simple connexion ADSL, on peut lancer un projet libre sur proche machine Linux en installant un serveur Subversion, voir une instance de Trac. Si le projet devient populaire, il toujours être migré sur un autre hébergeur plus tard (avec le risque de perdre l'historique).
Gestionnaire de source
Le plus connu dans le logiciel libre est Subversion. Il est basé sur un modèle centralisé : tout le monde envoie ses modifications sur le même serveur, et la dernière version est toujours récupérée sur ce même serveur.
Outils distribués permettant de travailler en mode déconnecté (sans réseau, pratique quand le serveur centré est hors service) : GIT, Mercurial, Bazar, etc.
Gestionnaire de projet
Un gestionnaire de projet doit centraliser la gestion des tickets (rapports d'anomalies, suggestions, gestion des incidents, etc.), permettre de suivre l'actualité du projet (ex: suivre les commits), offre un accès au code source (avec l'historique), voir également intégré un wiki. Le projet en vogue est Trac. Libre et gratuit, il s'installe facilement et intègre tous les besoins cités. Il supporte Subversion mais il semble possible d'utiliser d'autres gestionnaires de source comme Mercurial.
Publier une version
Procédure pour publier une nouvelle version d'un projet :
- Mettre à jour le journal des changements (Changelog)
- Augmenter le numéro de version (ex: 0.3 => 0.4)
- Créer un tag dans le gestionnaire de version (ex avec subversion: svn cp trunk tags/projet-0.4)
- Créer un tarball des sources
- Tester le projet à partir du tarball (et non pas à partir de la branche de développement trunk)
- Publier le tarball sur Internet (ex: Cheeseshop pour Python)
- Mettre à jour le site Internet du projet
- Annoncer la nouvelle version (ex: freshmeat, linuxfr)
Il est bon d'essayer de sortir une nouvelle version du projet le plus souvent possible. Au pire, une version tous les six mois, au mieux une version tous les mois. Publier régulièrement de nouvelles versions est bénéfique à la fois pour le développeur : si un bug est trouvé, il est plus simple à isoler si les changements sont réduits; et pour l'utilisateur : l'installation de la nouvelle version sera plus facile les fichiers de configuration n'ont pas trop changés et que les fonctionnalités changent peu.
De nouvelles versions fréquentes montre que le projet est actif. Les utilisateurs seront plus tentés pour tester les nouvelles versions. Il y a donc plus de retours des utilisateurs, ce qui motive les développeurs.
Lorsque vous annoncez une nouvelle version, n'insistez pas sur les changements du code source, mais placez vous du point de vue de l'utilisateur. De plus, n'hésitez pas à présenter brièvement votre projet ne quelques phrases au début de l'annonce. Il faut se mettre à la place de l'utilisateur : quel intérêt aurait-il à utiliser votre projet ? N'hésitez pas à en donner les usages courants.
Rédiger la liste des changements
Lorsque le développement d'un projet est intensif, rien ne sert de mettre à jour le journal des changements. Il vaut mieux le faire lorsqu'on publie la nouvelle version de l'outil en comparant la nouvelle version avec la précédente. Un journal de changement exhaustif n'intéresse personne, il vaut mieux être synthétique et insister sur les changements visibles.
Vous pouvez utiliser le logiciel meld, idéal pour comparer deux versions d'un même projet. Il permet de comparer deux répertoires et affichant en gras les fichiers modifiés.
