Chi gestisce un sito o un gestionale in PHP si trova prima o poi davanti a domande molto pratiche: fino a quando la versione che usiamo riceverà correzioni? Quando conviene pianificare il prossimo aggiornamento? Perché un ramo uscito pochi anni fa risulta già “fuori supporto” nel report di un auditor? Le risposte stanno tutte nel ciclo di vita delle versioni di PHP, che il progetto pubblica in modo chiaro ma che pochi leggono finché non diventa un problema.
In questo articolo spieghiamo come sono numerate le versioni, come nasce un nuovo ramo ogni anno, cosa succede nelle tre fasi di supporto attivo, solo sicurezza e fine vita, cosa è cambiato con la riforma del 2024 e come leggere il calendario ufficiale per pianificare gli aggiornamenti con mesi di anticipo invece che in emergenza.
Come si leggono i numeri di versione
Un numero di versione di PHP ha tre parti. Prendiamo PHP 8.3.12 come esempio:
- 8 è la versione principale (major): cambia di rado, dopo molti anni, e porta con sé le rotture di compatibilità più profonde, come il passaggio da PHP 7 a PHP 8;
- 8.3 è il ramo, cioè la versione minore: ne esce uno nuovo ogni anno e il ciclo di vita si calcola sempre a livello di ramo;
- 12 è il rilascio di manutenzione (patch) dentro il ramo: contiene correzioni di bug e di sicurezza, senza nuove funzionalità.
La distinzione conta perché i due tipi di aggiornamento hanno un peso molto diverso. Passare da 8.3.11 a 8.3.12 è un’operazione di routine, da fare con regolarità. Passare da 8.3 a 8.4 significa cambiare ramo: il codice deve essere compatibile con le funzionalità rimosse o deprecate, e serve un ciclo di test sull’applicazione reale. Quando si parla di “fine del supporto” si parla sempre di un ramo intero: il giorno in cui un ramo esce dal supporto, nessun rilascio di quel ramo riceverà più correzioni.
Un nuovo ramo ogni anno
Il progetto PHP pubblica un nuovo ramo ogni anno, verso la fine di novembre. Il lavoro segue un calendario pubblico sul wiki del progetto, con una coppia o un piccolo gruppo di release manager responsabili di ciascun ramo per tutta la sua vita. Le tappe sono sempre le stesse:
- alpha, in estate: le prime versioni di prova, con le nuove funzionalità già approvate;
- beta e feature freeze: da questo momento non entrano più funzionalità nuove, solo correzioni;
- release candidate: versioni candidate al rilascio, una ogni due settimane, su cui la comunità e i manutentori dei framework fanno i loro test;
- rilascio generale (GA), la prima versione stabile del ramo, per esempio 8.4.0.
Per PHP 8.4 il feature freeze è caduto il 13 agosto 2024, la prima release candidate è uscita il 26 settembre e il rilascio stabile il 21 novembre 2024. Per PHP 8.6, che è in lavorazione mentre scriviamo, il calendario pubblicato sul wiki prevede il feature freeze definitivo il 22 settembre 2026 e il rilascio stabile il 19 novembre 2026. Sono date di pianificazione e possono spostarsi di qualche settimana se emerge un problema bloccante nelle ultime release candidate.
Le tre fasi di ogni ramo
Dal giorno del rilascio stabile parte il conto alla rovescia. Ogni ramo attraversa tre fasi, e per ciascuna è chiaro cosa riceve e cosa no.
Supporto attivo
Per i primi due anni il ramo riceve correzioni di bug e di sicurezza in rilasci regolari, di norma circa una volta al mese. È la fase in cui conviene stare, perché i problemi segnalati vengono corretti, il comportamento si stabilizza e i framework e i CMS aggiungono il ramo alle versioni ufficialmente compatibili. Un ramo appena uscito però merita qualche settimana di prudenza: i primi rilasci di manutenzione correggono spesso difetti emersi solo con l’uso su larga scala.
Solo sicurezza
Nei due anni successivi il ramo riceve solo le correzioni per le vulnerabilità, e i rilasci escono quando servono: possono essercene diversi in pochi mesi oppure nessuno per un lungo periodo. I bug ordinari non vengono più corretti, con un’eccezione introdotta nel 2024: si possono correggere le regressioni causate da modifiche entrate nel ramo negli ultimi dodici mesi. In questa fase l’applicazione è ancora protetta, ma è il momento giusto per preparare il passaggio al ramo successivo.
Fine vita
Dopo quattro anni il ramo entra in End of Life e il progetto non pubblica più alcun rilascio, nemmeno per una falla critica sfruttabile da remoto. Le conseguenze pratiche di questa fase, per la sicurezza, la conformità e la gestione operativa, le abbiamo descritte in dettaglio nell’articolo su cosa significa PHP End of Life.
Cosa è cambiato nel 2024
Per molti anni la regola è stata di due anni di supporto attivo e uno di sola sicurezza, con la fine del supporto calcolata dalla data di rilascio. Con questa regola un ramo usciva il 26 novembre e il supporto finiva tre anni dopo, il 26 novembre: è esattamente quello che è successo a PHP 8.0. Nell’aprile 2024 la comunità ha approvato la RFC “Release cycle update”, che ha introdotto alcune modifiche importanti:
- un anno in più di sola sicurezza: il ciclo completo passa da tre a quattro anni, due di supporto attivo e due di sicurezza;
- fine allineata al 31 dicembre: le scadenze cadono sempre alla fine dell’anno, più facili da ricordare e da inserire nei budget;
- correzione delle regressioni anche durante la fase di sola sicurezza, per le modifiche degli ultimi dodici mesi;
- quattro release candidate invece di sei prima del rilascio stabile, senza nuove funzionalità nelle release candidate.
Le modifiche sono entrate in vigore subito per tutti i rami allora supportati, dalla 8.2 in poi, e PHP 8.1, che era già in sola sicurezza, ha ricevuto anch’esso l’anno aggiuntivo. Per questo i rami recenti hanno scadenze diverse da quelle che si leggevano negli articoli di qualche anno fa.
| Ramo | Rilascio | Fine del supporto attivo | Fine del supporto di sicurezza |
|---|---|---|---|
| PHP 8.0 | 26 novembre 2020 | 26 novembre 2022 | 26 novembre 2023 |
| PHP 8.1 | 25 novembre 2021 | 25 novembre 2023 | 31 dicembre 2025 |
| PHP 8.2 | 8 dicembre 2022 | 31 dicembre 2024 | 31 dicembre 2026 |
| PHP 8.3 | 23 novembre 2023 | 31 dicembre 2025 | 31 dicembre 2027 |
| PHP 8.4 | 21 novembre 2024 | 31 dicembre 2026 | 31 dicembre 2028 |
| PHP 8.5 | 20 novembre 2025 | 31 dicembre 2027 | 31 dicembre 2029 |
La riforma ha anche una nota per chi usa PHP su Windows: le librerie esterne incluse nelle build ufficiali per Windows potrebbero non essere aggiornate per tutto il periodo di sicurezza, e il progetto chiede agli utenti di seguirle in autonomia. Sui server Linux, dove PHP arriva dai pacchetti della distribuzione o di un repository, il tema non si pone negli stessi termini.
Dove siamo a settembre 2026
Applicando le regole alle date ufficiali, il quadro di questo autunno è il seguente:
- PHP 8.0 e 8.1 sono fuori supporto, rispettivamente da novembre 2023 e da dicembre 2025;
- PHP 8.2 è nell’ultimo trimestre di sola sicurezza: dal 1° gennaio 2027 non riceverà più correzioni ufficiali;
- PHP 8.3 è in sola sicurezza fino alla fine del 2027;
- PHP 8.4 è in supporto attivo fino alla fine del 2026, poi in sicurezza fino alla fine del 2028;
- PHP 8.5 è in supporto attivo fino alla fine del 2027 e in sicurezza fino alla fine del 2029;
- PHP 8.6 è in fase di beta, con le release candidate da fine settembre e il rilascio previsto il 19 novembre 2026.
Per PHP 8.6 le date di fine supporto non sono ancora sulla pagina ufficiale, che le aggiunge al rilascio. Con la regola dei quattro anni dovrebbero essere la fine del 2028 per il supporto attivo e la fine del 2030 per la sicurezza, ma conviene sempre attendere la pubblicazione su php.net prima di inserirle in un piano.
Come leggere il calendario ufficiale
Le fonti da consultare sono due pagine di php.net. La pagina dei rami supportati mostra, per ogni ramo vivo, la data del rilascio iniziale, la fine del supporto attivo e la fine del supporto di sicurezza, insieme a un grafico colorato con la data di oggi. La pagina dei rami non più supportati elenca invece tutti i rami chiusi, con la data di fine vita e l’ultimo rilascio pubblicato: per esempio 7.4.33 per PHP 7.4 e 8.1.34 per PHP 8.1.
Il secondo dato da controllare è il rilascio di manutenzione. Essere su un ramo supportato serve a poco se il server è fermo a una patch di due anni fa. php.net espone l’ultima versione di ogni ramo anche in formato JSON, comodo da confrontare con quella installata:
# Versione installata sul server (riga di comando)
php -r 'echo PHP_VERSION, PHP_EOL;'
# Ultimo rilascio pubblicato per il ramo 8.3
curl -s 'https://www.php.net/releases/index.php?json&version=8.3' | grep -o '"version":"[^"]*"'C’è un’avvertenza importante. Sui server Linux il numero di versione non basta, perché le distribuzioni come Debian, Ubuntu e Red Hat Enterprise Linux spesso mantengono il numero di patch con cui è uscita la release e applicano le correzioni con patch proprie, indicate nella revisione del pacchetto. Su Ubuntu 22.04, per esempio, il pacchetto di PHP 8.1 riporta ancora la versione 8.1.2, seguita da un numero di revisione che cresce a ogni correzione di sicurezza. Per capire cosa gira davvero sul server, e da quale fonte arriva, abbiamo dedicato un articolo a come scoprire quale versione di PHP stai usando.
Cosa significa per chi gestisce applicazioni in produzione
Il ciclo di quattro anni con scadenza al 31 dicembre rende la pianificazione molto più semplice di un tempo. Ogni ramo ha una data di fine nota con anni di anticipo, e il ramo successivo esce sempre a novembre, poche settimane prima di una scadenza. Da qui alcune regole pratiche:
- aggiorna le patch con regolarità: i rilasci di manutenzione dentro lo stesso ramo vanno applicati come gli aggiornamenti di sicurezza del sistema operativo, senza aspettare;
- scegli il ramo di arrivo guardando la sua scadenza: con un’applicazione che si aggiorna raramente conviene il ramo più recente compatibile con CMS, framework e librerie, così da avere più anni davanti;
- pianifica il cambio di ramo durante la fase di sola sicurezza: è la finestra in cui l’applicazione è ancora protetta e c’è il tempo di testare senza pressione;
- allinea il calendario di PHP a quello del sistema operativo: la versione inclusa nella distribuzione e la sua durata possono essere diverse da quelle del progetto, in entrambe le direzioni;
- metti le scadenze nel budget: una migrazione di ramo ogni due o tre anni è un costo prevedibile, una migrazione d’urgenza dopo anni di ritardo no.
Chi oggi è su PHP 8.2 ha davanti l’ultimo trimestre di supporto, e ne parleremo nel dettaglio nell’articolo dedicato. Chi è già su un ramo chiuso ha due strade da combinare: proteggere la produzione con pacchetti ancora mantenuti o con il backport delle patch, e pianificare la migrazione verso un ramo supportato.
Riassumendo
PHP pubblica un nuovo ramo ogni anno, a fine novembre, dopo un percorso pubblico di alpha, beta e release candidate. Dalla riforma approvata nel 2024 ogni ramo ha due anni di supporto attivo, con correzioni di bug e di sicurezza, e due anni di sola sicurezza, con scadenza sempre al 31 dicembre; poi entra in End of Life e non riceve più nulla. A settembre 2026 sono supportati i rami dall’8.2 all’8.5, con l’8.2 in chiusura alla fine dell’anno e l’8.6 in arrivo a novembre. Le date ufficiali sono su php.net e vanno lette insieme a due dati concreti del server: il rilascio di manutenzione installato e chi mantiene il pacchetto. Con queste informazioni il cambio di ramo diventa un’attività pianificata, da fare durante la fase di sola sicurezza invece che dopo la scadenza.
