PHP
Bijdragen aan de PHP Core

PHP is een open source project en als zodanig kan iedereen hieraan bijdragen. In grote lijnen zijn er twee manieren om bij te dragen aan de PHP-kern:

• Bug repareren
• Toevoegingen van functies

Voordat u bijdraagt, is het echter belangrijk om te begrijpen hoe PHP-versies worden beheerd en vrijgegeven, zodat bugfixes en functieverzoeken de juiste PHP-versie kunnen targeten. De ontwikkelde wijzigingen kunnen als pull-verzoek worden ingediend bij de PHP Github-repository . Nuttige informatie voor ontwikkelaars is te vinden in de sectie "Doe mee" van de PHP.net-site en het #externals forum .

Bijdragen met bugfixes

Voor diegenen die willen bijdragen aan de kern, is het over het algemeen gemakkelijker om met bugfixing te beginnen. Dit helpt om vertrouwd te raken met de interne functies van PHP voordat wordt geprobeerd complexere wijzigingen aan te brengen in de kern die een functie zou vereisen.

Wat betreft het versiebeheerproces, moeten bugfixes de minst getroffen zijn, terwijl ze nog steeds PHP-versie ondersteunen . Het is deze versie waarop bug-reparaties pull-verzoeken moeten richten. Van daaruit kan een internals-lid de fix in de juiste vertakking samenvoegen en deze indien nodig naar boven naar latere PHP-versies samenvoegen.

Degenen die aan de slag willen gaan met het oplossen van bugs, kunnen een lijst met bugrapporten vinden op bugs.php.net .

Bijdragen met functietoevoegingen

PHP volgt een RFC-proces bij het introduceren van nieuwe functies en het aanbrengen van belangrijke wijzigingen in de taal. RFC's worden gestemd door leden van php.net en moeten een eenvoudige meerderheid (50% + 1) of een super meerderheid (2/3 + 1) van het totale aantal stemmen behalen. Een super meerderheid is vereist als de wijziging de taal zelf beïnvloedt (zoals het invoeren van een nieuwe syntaxis), anders is slechts een eenvoudige meerderheid vereist.

Voordat RFC's kunnen worden gestemd, moeten ze een discussieperiode van minimaal 2 weken doorlopen op de officiële PHP-mailinglijst. Zodra deze periode is verstreken en er geen openstaande problemen met de RFC zijn, kan deze worden omgezet in stemming, die minimaal 1 week moet duren.

Als een gebruiker een eerder afgekeurde RFC wil laten herleven, kan dit alleen onder een van de volgende twee omstandigheden:

• 6 maanden zijn verstreken sinds de vorige stemming
• De auteur (s) brengen voldoende ingrijpende wijzigingen aan in de RFC die waarschijnlijk invloed hebben op de uitkomst van de stemming als de RFC opnieuw in stemming wordt gebracht.

De mensen die het voorrecht hebben om te stemmen, zullen ofwel bijdragen aan PHP zelf (en dus ook php.net-accounts hebben), of vertegenwoordigers zijn van de PHP-gemeenschap. Deze vertegenwoordigers worden gekozen door mensen met php.net-accounts en zullen ofwel hoofdontwikkelaars zijn van PHP-gebaseerde projecten of regelmatige deelnemers aan interne discussies.

Bij het indienen van nieuwe ideeën voor het voorstel is het bijna altijd vereist dat de indiener op zijn minst een patch voor het concept van het concept schrijft. Dit komt omdat zonder een implementatie de suggestie gewoon een ander functieverzoek wordt waaraan in de nabije toekomst waarschijnlijk niet zal worden voldaan.

Een grondige procedure voor dit proces is te vinden op de officiële How To Create a RFC- pagina.

Releases

Belangrijke PHP-versies hebben geen vaste releasecyclus en kunnen daarom worden vrijgegeven naar goeddunken van het interne team (wanneer ze dit nodig achten voor een nieuwe grote release). Kleine versies worden daarentegen jaarlijks uitgegeven.

Voorafgaand aan elke release in PHP (major, minor of patch) wordt een reeks releasekandidaten (RC's) beschikbaar gesteld. PHP maakt geen gebruik van een RC zoals andere projecten doen (dwz als een RC er geen problemen mee heeft gevonden, maak het dan als de volgende definitieve release). In plaats daarvan worden ze gebruikt als een vorm van definitieve bèta's, waarbij meestal een bepaald aantal RC's wordt bepaald voordat de definitieve release wordt gemaakt.

Versioning

PHP probeert in het algemeen waar mogelijk semantische versiebeheer te volgen. Als zodanig moet backwards compatibiliteit (BC) worden gehandhaafd in secundaire en patchversies van de taal. Functies en wijzigingen die BC behouden, moeten zich richten op secundaire versies (geen patchversies). Als een functie of wijziging het potentieel heeft om BC te verbreken, dan moeten ze zich richten op de volgende belangrijke PHP-versie ( X .yz).

Elke secundaire PHP-versie (x. Y .z) heeft twee jaar algemene ondersteuning (zogenaamde "actieve ondersteuning") voor alle soorten bugfixes. Bovendien wordt een extra jaar toegevoegd voor beveiligingsondersteuning, waarbij alleen beveiligingsgerelateerde fixes worden toegepast. Nadat de drie jaar voorbij zijn, wordt de ondersteuning voor die versie van PHP volledig weggelaten. Een lijst met momenteel ondersteunde PHP-versies is te vinden op php.net .