PHP
Contribuer au noyau PHP

PHP est un projet open source et, à ce titre, n'importe qui peut y contribuer. En gros, il existe deux manières de contribuer au noyau PHP:

• Correction de bug
• Ajout de fonctionnalités

Avant de contribuer, il est important de comprendre comment les versions de PHP sont gérées et publiées afin que les corrections de bogues et les demandes de fonctionnalités puissent cibler la version correcte de PHP. Les modifications développées peuvent être soumises en tant que requête pull au dépôt PHP Github . Des informations utiles pour les développeurs peuvent être trouvées dans la section "Impliquez-vous" du site PHP.net et du forum #externals .

Contribuer avec des corrections de bugs

Pour ceux qui cherchent à contribuer au noyau, il est généralement plus facile de commencer par corriger les bogues. Cela permet de se familiariser avec les éléments internes de PHP avant d'essayer d'apporter des modifications plus complexes au noyau requis par une fonctionnalité.

En ce qui concerne le processus de gestion des versions, les corrections de bogues devraient cibler les versions les plus faibles, tout en supportant la version PHP. C'est cette version que les requêtes d'extraction de bogues doivent cibler. A partir de là, un membre interne peut fusionner le correctif dans la bonne branche, puis le fusionner vers le haut vers les versions ultérieures de PHP si nécessaire.

Pour ceux qui cherchent à résoudre des bogues, une liste de rapports de bogues peut être trouvée sur bugs.php.net .

Contribuer avec des ajouts de fonctionnalités

PHP suit un processus RFC lorsqu'il introduit de nouvelles fonctionnalités et apporte des modifications importantes au langage. Les RFC sont votés par les membres de php.net et doivent atteindre une majorité simple (50% + 1) ou une super majorité (2/3 + 1) du total des votes. Une super majorité est requise si le changement affecte la langue elle-même (par exemple, l'introduction d'une nouvelle syntaxe), sinon seule une majorité simple est requise.

Avant que les RFC puissent être mis aux voix, ils doivent subir une période de discussion d'au moins 2 semaines sur la liste de diffusion officielle de PHP. Une fois que cette période est terminée et qu'il n'y a plus de problèmes en suspens avec le RFC, il est possible de passer au vote, qui doit durer au moins une semaine.

Si un utilisateur souhaite réactiver une RFC précédemment rejetée, il ne peut le faire que dans l'une des deux circonstances suivantes:

• 6 mois se sont écoulés depuis le vote précédent
• L'auteur (s) apporte des modifications suffisamment importantes au RFC qui pourraient affecter le résultat du vote si le RFC devait être à nouveau mis aux voix.

Les personnes qui ont le privilège de voter seront soit des contributeurs à PHP lui-même (et donc des comptes php.net), soit des représentants de la communauté PHP. Ces représentants sont choisis par ceux qui ont des comptes php.net et seront soit des développeurs en chef de projets basés sur PHP, soit des participants réguliers à des discussions internes.

Lorsque vous soumettez de nouvelles idées à la proposition, il est presque toujours nécessaire que l'auteur de la proposition écrive, à tout le moins, un correctif de validation de principe. En effet, sans une implémentation, la suggestion devient simplement une autre demande de fonctionnalité qui ne sera probablement pas remplie dans un avenir proche.

Vous trouverez une explication complète de ce processus sur la page officielle Comment créer une RFC .

Les rejets

Les principales versions de PHP n'ont pas de cycle de publication défini et peuvent donc être publiées à la discrétion de l'équipe interne (à chaque fois qu'une nouvelle version majeure est nécessaire). Les versions mineures, par contre, sont publiées chaque année.

Avant chaque version en PHP (majeure, mineure ou patch), une série de versions candidates (RC) est disponible. PHP n'utilise pas de RC comme le font les autres projets (c.-à-d. Si un RC ne rencontre pas de problème, alors faites-en la prochaine version finale). Au lieu de cela, il les utilise comme une forme de bêta finale, où généralement un nombre défini de RC est décidé avant la publication finale.

Versioning

PHP essaie généralement de suivre les versions sémantiques lorsque cela est possible. En tant que tel, la compatibilité ascendante (BC) devrait être maintenue dans les versions mineures et correctives du langage. Les fonctionnalités et les modifications qui préservent la BC doivent cibler les versions mineures (et non les versions de correctifs). Si une fonctionnalité ou un changement a le potentiel de casser BC, ils devraient plutôt viser la prochaine version majeure de PHP ( X. Yz).

Chaque version mineure de PHP (x. Y .z) a deux ans de support général (appelé "support actif") pour tous les types de corrections de bogues. Une année supplémentaire est ajoutée pour la prise en charge de la sécurité, où seuls les correctifs liés à la sécurité sont appliqués. Après trois ans, le support de cette version de PHP est complètement supprimé. Une liste des versions de PHP actuellement prises en charge est disponible sur php.net .