PHP
Contribuire al core PHP

PHP è un progetto open source, e come tale, chiunque è in grado di contribuire ad esso. A grandi linee, ci sono due modi per contribuire al core PHP:

• Bug fixing
• Aggiunte di funzionalità

Prima di contribuire, tuttavia, è importante capire come vengono gestite e rilasciate le versioni di PHP in modo che le correzioni dei bug e le richieste di funzionalità possano essere indirizzate alla versione corretta di PHP. Le modifiche sviluppate possono essere inviate come richiesta pull al repository Github di PHP . Informazioni utili per gli sviluppatori sono disponibili nella sezione "Partecipa" del sito PHP.net e nel forum #externals .

Contribuire con correzioni di bug

Per coloro che cercano di iniziare a contribuire al nucleo, in genere è più facile iniziare con il bug fixing. Ciò aiuta a familiarizzare con gli interni di PHP prima di tentare di apportare modifiche più complesse al core che una funzionalità richiederebbe.

Per quanto riguarda il processo di gestione delle versioni, le correzioni dei bug dovrebbero essere rivolte ai meno colpiti, pur continuando a supportare la versione di PHP. È questa versione che le richieste di pull di bug fixing dovrebbero essere indirizzate. Da lì, un membro interno può unire la correzione nel ramo corretto e quindi unirlo a versioni successive di PHP, se necessario.

Per coloro che desiderano iniziare a risolvere i bug, è possibile trovare un elenco di segnalazioni di errori su bugs.php.net .

Contribuire con aggiunte di funzionalità

PHP segue un processo RFC quando introduce nuove funzionalità e apporta modifiche importanti al linguaggio. Le RFC sono votate dai membri di php.net e devono raggiungere una maggioranza semplice (50% + 1) o una super maggioranza (2/3 + 1) dei voti totali. Una super maggioranza è necessaria se la modifica influisce sulla lingua stessa (come ad esempio l'introduzione di una nuova sintassi), altrimenti è richiesta solo una maggioranza semplice.

Prima che le RFC possano essere votate, devono essere sottoposte a un periodo di discussione di almeno 2 settimane sulla mailing list ufficiale di PHP. Una volta che questo periodo è terminato e non ci sono problemi aperti con la RFC, può essere spostato in votazione, che deve durare almeno 1 settimana.

Se un utente desidera ripristinare una RFC precedentemente rifiutata, può farlo solo in una delle seguenti due circostanze:

• 6 mesi sono passati dal voto precedente
• Gli autori apportano modifiche sostanziali alla RFC che potrebbero influire sul risultato del voto nel caso in cui la RFC venga nuovamente votata.

Le persone che hanno il privilegio di votare contribuiranno allo stesso PHP (e così avranno account php.net), o saranno rappresentanti della comunità PHP. Questi rappresentanti sono scelti da coloro che hanno account php.net e saranno sia sviluppatori principali di progetti basati su PHP che partecipanti regolari a discussioni interne.

Quando si inviano nuove idee per la proposta, è quasi sempre necessario che il proponente scriva almeno una patch proof-of-concept. Questo perché senza un'implementazione, il suggerimento diventa semplicemente un'altra richiesta di funzionalità che difficilmente si realizzerà nel prossimo futuro.

Un approfondito how-to di questo processo può essere trovato nella pagina ufficiale Come creare una RFC .

Uscite

Le versioni principali di PHP non hanno un ciclo di rilascio impostato, e quindi possono essere rilasciate a discrezione del team interno (ogni volta che ritengono opportuno una nuova versione principale). Le versioni minori, d'altra parte, vengono rilasciate ogni anno.

Prima di ogni versione in PHP (maggiore, minore o patch), sono disponibili una serie di release candidate (RCs). PHP non usa un RC come fanno altri progetti (cioè se un RC non ha riscontrato problemi con esso, quindi rendilo come la prossima versione finale). Invece, li usa come una forma di beta finale, dove in genere viene deciso un determinato numero di RC prima che venga rilasciata la versione finale.

versioning

PHP in genere tenta di seguire il versioning semantico dove possibile. Pertanto, la retrocompatibilità (BC) dovrebbe essere mantenuta in versioni minori e patch della lingua. Le caratteristiche e le modifiche che preservano BC dovrebbero essere indirizzate a versioni minori (non versioni di patch). Se una funzionalità o un cambiamento ha il potenziale per interrompere BC, allora dovrebbero mirare a indirizzare la successiva versione principale di PHP ( X .yz).

Ogni versione minore di PHP (x. Y .z) ha due anni di supporto generale (il cosiddetto "supporto attivo") per tutti i tipi di correzioni di bug. Un altro anno in più viene aggiunto per il supporto di sicurezza, dove vengono applicate solo correzioni relative alla sicurezza. Dopo che i tre anni sono scaduti, il supporto per quella versione di PHP è completamente abbandonato. Un elenco delle versioni PHP attualmente supportate può essere trovato su php.net .