Ieri (24 febbraio 2025) è uscito Laravel 12. Questo mi dà lo spunto per parlare di quanto sia importante (e perché lo sia) aggiornare sempre le proprie applicazioni affinché usino l'ultima versione del framework.

Che palle, devo proprio aggiornare?

Risposta breve: sì, devi. Per vari motivi.

Utilizzare la versione più aggiornata del framework ti consente di:

• usufruire delle ultime funzionalità rilasciate su Laravel: nuovi metodi Eloquent o sulle Collection, nuovi helper o facade, classi con una sintassi fluente e più gradevole, wrapper di funzioni PHP relative a versioni recenti, nuovi asserzioni nei metodi di test, eccetera
• beneficiare delle più recenti correzioni relative alla sicurezza
• utilizzare package di prima parte (es. Reverb, Pulse, Pennant, ecc.) che non sono disponibili per versioni meno recenti
• utilizzare tecnologie, protocolli, prodotti o API supportati solo dalle più recenti versioni del framework
• poter utilizzare le versioni più aggiornate dei package di terze parti necessari alla tua applicazione, usufruendo così delle aggiunte rilasciate
• godere di una DX (Developer eXperience) di alto livello, grazie anche agli strumenti pensati per le versioni più recenti del framework (es. Pest, Pint, Larastan, Rector, ecc.) o alle funzionalità messe a disposizione dalle ultime release di PHP (sintassi, nuovi operatori, attributi, correzioni varie)

In poche parole, tutto ciò ti consente di non restare indietro ed evitare di andare incontro a obsolescenza certa.

Non voglio aggiornare

Puoi anche decidere di non farlo, ma credimi: questa decisione, prima o poi, ti si ritorcerà contro. Parlo per esperienza diretta! 😁
Supponiamo, ad esempio, che mantieni un'applicazione importante, con una codebase piuttosto grossa, scritta con Laravel 7. Per vari motivi, non l'hai mai aggiornata. Il codice ha sempre funzionato senza problemi; il cliente ogni tanto ha chiesto qualche modifica e tu l'hai realizzata; hai sempre sistemato i bug che si sono presentati nel tempo. Nel frattempo, siccome non vivi nelle caverne e ami tenerti aggiornato, hai sempre tenuto d'occhio le novità nel mondo Laravel: nuove funzionalità, strumenti da riga di comando, analizzatori statici, framework per i test, linter, package fantastici, eccetera. Peccato che tutto ciò tu non lo possa usare perché è disponibile, diciamo, dalla versione 10 di Laravel in poi. Inoltre, la tua applicazione gira ancora con PHP 7.x, quindi fino ad ora hai dovuto anche rinunciare ad usare la sintassi e tutte le comodità della versione 8.x. Per non parlare del fatto che il supporto a PHP 7.x è cessato da un pezzo, per cui vai incontro a possibili problemi di sicurezza e con il tempo diventa complicato configurare un VPS con stack applicativi obsoleti (e magari non sei proprio a tuo agio con Docker).
All'improvviso hai bisogno di introdurre notifiche in tempo reale via websocket. Perfetto, c'è Laravel Reverb! Peccato che tu non lo possa usare perché richiede almeno la versione 10!

A un certo punto valuti anche di riscrivere l'applicazione da zero, partendo da laravel new e riciclando parti di codice prese dalla attuale applicazione. La scarti quasi immediatamente: troppo lungo e complicato.
Non hai scampo: sei costretto ad aggiornare. Buona fortuna! 😁 Passare dalla versione N alla N+1 di Laravel può essere relativamente semplice; ma passare da N a N+5 può essere un vero inferno. E ti maledirai per aver aspettato così tanto tempo. Avrai a che fare con

• package non più supportati
• vari breaking change del framework
• svariati breaking change in più di un package che utilizzi nell'applicazione
• codice deprecato che va riscritto per una versione più attuale di PHP e/o di Laravel
• molto altro ancora a cui ora non voglio nemmeno pensare ma che si tradurrà sicuramente in mal di testa, ora spese a cercare in rete, attimi di disperazione

Quando mi conviene aggiornare?

Non immediatamente, ma non fare passare troppo tempo.
Subito potrebbe essere prematuro: potresti andare incontro a problemi, bug o casi particolari per cui non trovi (ancora) soluzioni negli issue di GitHub, su StackOverflow, su Reddit né tantomeno su ChatGPT e simili. Anche se volessi avventurarti, potresti scontrarti con dipendenze Composer non ancora pronte: package che non supportano ancora l'ultima versione di Laravel.

Quando esce una nuova versione di Laravel, molti addetti ai lavori sono in fibrillazione già da tempo, principalmente per aggiornare i propri package affinché siano installabili anche sulla versione più recente del framework. Il panorama è variegato:

• chi si porta avanti con largo anticipo, rilasciando una nuova versione già parecchi giorni o, a volte, addirittura settimane prima: fra questi, ad esempio, la nostra web agency spaziale belga preferita 😁
• all'opposto, chi aggiorna il proprio package con settimane o addirittura mesi di ritardo, costringendo chi lo utilizza a non poter aggiornare la propria applicazione o a dover trovare un'alternativa (fork, altro package, ecc.)
• chi aiuta altri maintainer aprendo un Pull Request che realizza l'aggiornamento: è un buon metodo per essere utili e riconoscenti alla comunità open-source, per imparare qualcosa di nuovo e, non ultimo, per velocizzare i tempi di uscita di quel package
• chi decide di non aggiornare il proprio package

Si tratta di variabili di cui bisogna necessariamente tenere conto.

Lo farò un giorno. Ora ho problemi più urgenti

Ok, ma non fare passare troppo tempo. Pianifica questa attività, metti un promemoria e trova il tempo per portarla a termine. Non te ne pentirai. Se lasci passare troppo tempo, finirai per dimenticartene e potresti ritrovarti anni dopo nell'inferno descritto più sopra.

Il cliente non mi paga, quindi non aggiorno

In breve: dovresti aggiornare comunque.

Sulla carta, il ragionamento non fa una piega: niente soldi, niente cammello. Peccato che non vendi frutta o abiti ma software e servizi (che vanno necessariamente mantenuti e aggiornati).

Magari hai anche provato a spiegare il problema al tuo cliente, ma lui ha risposto

"l'applicazione sta funzionando. Non possiamo permetterci di spendere altri soldi; al limite, preferisco tenerli da parte per sviluppi futuri"

C'è un grosso errore di fondo: non spetta al cliente prendere questo tipo di decisioni. Non avresti nemmeno dovuto porgli questa domanda: il più delle volte, il cliente non ha le competenze tecniche per valutare se e quando sia meglio aggiornare un framework o che versione di PHP sia più opportuno usare. E se le ha (ad esempio, ti interfacci con il dipartimento IT), dà per scontato che tu segua le best practice relative a manutenzione, aggiornamento, sicurezza. Si aspetta, quindi, che prenda tu questo genere di decisioni, eventualmente discutendo con lui eventuali problematiche legate a costi o periodi in cui l'applicazione non può essere utilizzata dagli utenti causa aggiornamento/manutenzione.

Quindi ci devo rimettere io?

Risposta breve: non ci rimetti tu. Anzi.

Il tuo primo pensiero potrebbe essere questo:

"ora dovrò perdere ore per aggiornare versione del framework, combattendo contro conflitti di versione tra package e test che non ne vogliono sapere di passare. Nessuno mi paga queste ore. Chi me lo fa fare?"

Partiamo dalla questione economica: probabilmente stai sbagliando qualcosa nella parte contrattuale/economica con il cliente. Siamo d'accordo: non puoi emettere una fattura dove indichi aggiornamento Laravel alla versione 12 o aggiornamento di spatie/laravel-permission. Tuttavia, si presume che tu abbia previsto un canone mensile o annuo relativo a supporto, aggiornamento e manutenzione applicativa: gli aggiornamenti di Laravel, delle sue dipendenze e simili rientrano in questi compensi. Se non sei proprio alle prime armi e non hai previsto un canone simile, la vedo così: o hai sbagliato cliente o hai sbagliato lavoro. So che suona un po' duro e antipatico, ma è la realtà.

Non solo non ci rimetterai, ma ne guadagnerai anche, per i motivi spiegati sopra: avrai una DX più piacevole, potrai realizzare nuove funzionalità in modo più sicuro e "moderno", manterrai aggiornata la tua applicazione nel lungo termine.

Ok, mi hai convinto: come faccio?

Test, test, e ancora test: per cominciare, la tua applicazione deve avere una suite di test la più completa possibile (no, non serve una coverage né del 100% né del 75% perché sono numeri che di per sé non vogliono dire molto). Questo è il metodo più rapido per vedere se qualcosa "si rompe" o se continua a funzionare tutto dopo l'aggiornamento. Attenzione: se tutti i test passano, non hai la garanzia assoluta che sia tutto funzionante al 100%; allo stesso tempo, se dopo l'aggiornamento un test non passa più, hai l'evidenza della presenza di un bug. Come disse Edsger Dijkstra:

"Il test di un programma può essere usato per mostrare la presenza di bug, ma mai per mostrare la loro assenza"

A meno che la tua applicazione non sia una semplice landing page (volendo si potrebbe discutere sull'utilità di vari tipi di test anche per un caso così semplice) e testare a mano le funzionalità ti richieda due minuti, pensare di fare la stessa cosa per un'applicazione più grande o complessa è decisamente fuori discussione. Richiederebbe troppo tempo, sarebbe un procedimento inesatto e incompleto e, sicuramente, non considereresti tutti gli scenari, i casi d'uso e gli input dell'utente.

Ovviamente, segui la guida. Ogni nuova versione di Laravel riporta una guida all'aggiornamento. Ad esempio, se passi dalla versione 11 alla 12, devi eseguire questi passaggi. Per fortuna, in questo caso si tratta di un aggiornamento con zero breaking change, quindi dovrebbe essere piuttosto semplice.

Altro passaggio obbligatorio: segui la guida all'aggiornamento dei package presenti fra le dipendenze.

Utilizza strumenti di sviluppo che ti aiutino a rendere più "moderno" e aggiornato il tuo codice: ad esempio, Larastan e Rector.

Oltra all'ambiente locale - che sia basato su Herd, Laragon, Docker o altro non importa - effettua un rilascio su un ambiente di staging o pre-produzione, dove più utenti (specialmente quelli finali) possano testare l'applicazione, possibilmente per diversi giorni. Puoi anche avere una suite con migliaia di test e decine di migliaia di asserzioni, ma i test utente sono comunque necessari.

Valuta eventualmente se farti aiutare da una soluzione automatizzata quale Laravel Shift.

Buon aggiornamento!