Conditions sur les paquets

Nous avons certaines demandes concernant le code ainsi que pour le mainteneur des paquets :

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

    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

  6. 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.

  7. 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.

    Si un paquet se retrouve sans gestionnaire et que personne ne souhaite assumer ce rôle, le paquet sera supprimé de PEAR.

Intégrer votre code (Previous) Comment participer dans les faits (Next)
Last updated: Sun, 29 Aug 2010 — Download Documentation
Do you think that something on this page is wrong? Please file a bug report or add a note.
View this page in:

User Notes:

There are no user contributed notes for this page.