Nous avons certaines demandes concernant le code ainsi que pour
le mainteneur des paquets :
Le code doit être conforme aux standards de codage.
Si vous souhaitez intégrer du code à
PEAR, que ce soit pour
mettre à jour un paquet existant ou pour en
créer un nouveau
, ce code doit se conformer à
un certain nombre de
standards de développement.
De nombreuses discussions ont abordé
l'intérêt de ce standard avant
et après sa mise en place.
Il en est ressorti que ce standard était
indispensable donc obligatoire.
Le code doit être sous une license appropriée.
Chaque paquet doit être sous une license OpenSource acceptée.
Si vous n'êtes pas sûr de votre license, vous pouvez opter pour la
license PHP. Le groupe PEAR
a fait une annonce sur les licenses,
qui fournit plus de détails concernant ce sujet.
Le code doit être disponible dans un dépôt de code public.
La dernière version du code source d'un paquet doit être diposnible
dans un système SCM public (Gestionnaire de
code source) comme le serveur CVS sur
cvs.php.net, le dépôt Subversion de
Google Code, ou sur les sites
comme SourceForge.
L'hébergement sur Google Code ou SourceForge est librement
accessible suivant les termes d'utilisation. L'accès en écriture à
cvs.php.net est disponible une fois que le paquet a été accepté
en tant que paquet PEAR.
La raison principale de ceci est qu'il doit y avoir un moyen pour les
utilisateurs et les développeurs PEAR d'accéder à la dernière version
du code afin de raison certains bogues ainsi que de fournir des
patchs.
Code Extensible et mises à jour.
Il faut toujours garder en tête que votre code
doit être extensible
et qu'on doit pouvoir facilement y ajouter de
nouvelles fonctionnalités.
Si il n'est pas possible d'ajouter de nouvelles
fonctionnalités à votre
code sans détruire la compatibilité ascendante,
il vaudrait mieux revoir
sa structure avant de le proposer pour PEAR.
Il peut être notamment intéressant de vous
pencher sur les possibilités
de programmation objet de PHP. Bien que les fonctionnalités objet
de PHP 4 ne soit pas encore complètes, leur utilisation vous aidera
certainement à créer un paquet avec du code extensible.
Il existe de nombreuses ressources sur la programmation orientée
objet. Nous vous recommandons pour un début, la page
Object-Oriented Programming
Concepts sur le site Java de SUN.
Formats de la documentation (texte brut, docbook)
Votre code doit être
fourni avec une documentation
dans un des formats suivants:
Si vous écrivez votre documentation en Docbook XML
et que le formatage
est valide, celle-ci peut être
automatiquement intégrée à la
documentation officielle de PEAR
que vous êtes actuellement en train de lire.
Note :
Depuis aout 2003, phpDocumentor
permet de convertir la documentation intégrée
à votre code ainsi que
des tutoriels externes en XML DocBook.
La version 1.2.2 ou supérieure de PhpDocumentor
est nécessaire.
Installez-le en utilisant la commande pear install
phpDocumentor.
Utilisez le convertisseur XML:DocBook/peardoc2:default sur
votre code source pour générer la documentation.
Le fichier devrait être directement
généré dans le répertoire
peardoc/lang/package,
lang devant être remplacé par
en, ou fr, etc.
Vous devez bien être conscient que la documentation
de votre code source ne
suffit pas!
Votre paquet doit également être accompagné
d'exemples d'utilisation,
voir de tutoriels complets.
Plus d'informations peuvent être trouvées dans la rubrique
Comment écrire
votre documentation
Test de régression .phpt ou format
PHPUnit
Tous les développeurs ont déjà été
confrontés à la frustration des bugs.
Ils font parties de la vie d'un programmeur.
Heureusement il existe quelques systèmes
qui permettent de les trouver et de les supprimer.
Les tests de régression doivent être inclus
dans chaque version stable d'un paquet
afin que les utilisateurs puissent les exécuter en cas de bug.
Des exemples de tests de régression .phpt peuvent
être trouvés dans le paquet
DB.
Pour trouver des exemples de tests
PHPUnit, vous pouvez regarder dans le paquet
Auth.
Le contributeur (<< vous >>) doit avoir la volonté
de fournir un support pour son paquet et de sortir de futures versions
corrigeant au moins les bugs découverts.
Si vous ne souhaitez pas offrir de support autour de votre
paquet sur une longue période, votre paquet n'aura pas
d'intérêt pour PEAR.
PEAR est le fournisseur standard de paquets pour PHP,
et cela implique de lourdes responsabilités.
Offrir du support ne
signifie pas de juste répondre aux question dans les
mailing lists:
Vous devez avoir la volonté,
non seulement de réparer les bugs
découverts, mais aussi d'intégrer
les mises à jour proposées par les utilisateurs,
si le code de celles-ci correspond aux spécifications
de votre paquet.
Si vous ne pouvez pas assurer le support de votre
paquet pendant une période donnée,
vous devez le signaler à la
mailing liste des développeurs PEAR
et désigner un remplaçant pour
cette période ou annoncer sur la
documentation du paquet que celui-ci
est en sommeil pour une certaine période.
| Avertissement |
Si un paquet se retrouve sans gestionnaire et que personne
ne souhaite assumer ce rôle,
le paquet sera supprimé de PEAR.
|
