Au fur et à mesure que s'accroît la charge de travail des gestionnaires d'archives comme Metalab, le site PSA ou le CPAN, les soumissions sont de plus en plus souvent traitées, en tout ou en partie, par des programmes (et non en totalité par des humains).
Il est donc très important que le nom de votre projet et celui de votre fichier d'archive suivent des règles précises, afin que des programmes informatiques puissent les analyser et les comprendre.
Vous faciliterez la vie à tout le monde en donnant à vos archives des noms dans le style GNU : un préfixe-racine alphanumérique tout en minuscules, suivi par un tiret, puis un numéro de version, une extension et d'autres suffixes.
Supposons que vous ayez un projet nommé "toto", qui en est à la version 1, mise à jour 2, niveau 3. S'il est composé d'une seule archive (sans doute le code source), voici à quoi devrait ressembler son nom :
L'archive des sources
Le fichier LSM (si vous l'envoyez à Metalab).
N'utilisez pas les noms suivants :
Beaucoup de programmes croiront qu'il s'agit du fichier d'archive d'un projet nommé `toto123', sans numéro de version.
Beaucoup de programmes croiront qu'il s'agit de l'archive d'un projet nommé `toto1' à la version 2.3.
Beaucoup de programmes prendront cela pour un projet nommé `toto-v1'.
Le caractère souligné est difficile à prononcer, à taper, et à retenir.
A moins que vous vouliez vraiment ressembler à un accroc du marketing. Là encore, c'est difficile à prononcer, à taper et à retenir.
Si vous voulez faire séparément une archive de sources et une archive de binaires, ou différentes archives de binaires, ou encore indiquer un certain type d'option de fabrication dans le nom de l'archive, rajoutez pour cela une extension après le numéro de version. Voici quelques exemples :
sources
binaires, type non spécifié
binaires ELF
binaires ELF liés statiquement
binaires pour SPARC
N'utilisez pas des noms comme `toto-ELF.1.2.3.tar.gz', car les programmes ont beaucoup de mal à séparer un infixe (tel que `ELF') de la racine du mot.
Un bon schéma d'appellation générique contient, dans l'ordre, les parties suivantes :
Certains projets ou communautés ont des conventions bien établies pour les noms et les numéros de version, et ces conventions ne sont pas toujours compatibles avec les conseils qui précèdent. Par exemple, les modules Apache ont en général des noms du genre mod_foo, et ils ont à la fois un numéro de version propre et le numéro de la version d'Apache avec laquelle ils fonctionnent. De même, les numéros de version des modules Perl peuvent être traités comme des nombres décimaux (par exemple, vous pouvez voir 1.303 à la place de 1.3.3), et les distributions s'appellent en général Foo-Bar-1.303.tar.gz pour la version 1.303 du module Foo::Bar.
Apprenez et respectez les conventions des communautés et développeurs spécialisés ; suivez les règles décrites ci-dessus dans le cas général.
Le préfixe-racine devrait être le même pour tous les fichiers d'un projet, et il devrait être facile à lire, à taper et à retenir. N'utilisez pas le caractère "souligné". Et ne mettez pas de majuscules ou de MajusculesIntérieures sans une très bonne raison -- cela dérange le trajet naturel de l'oeil humain, et vous aurez l'air de faire du marketing.
C'est difficile de s'y retrouver lorsque deux projets ont le même nom. Assurez-vous donc, dans la mesure du possible, qu'il n'y a pas de conflit de noms avant de publier votre première version. Deux bons endroits pour vérifier ceci sont l'index de Metalab et l'index des applications (appindex) à Freshmeat. Un autre endroit recommandé est SourceForge, en effectuant une recherche par nom.