Nel corso degli anni, seguendo da vicino l’evoluzione di Magento prima e di Adobe Commerce poi, ho imparato a distinguere due tipi di release: quelle che ti conviene installare e quelle su cui ti conviene fermarti. Sono due cose diverse. La 2.4.4, in arrivo nella prima parte di quest’anno, secondo me appartiene alla seconda categoria. Ed è un complimento.
Provo a spiegare perché, e soprattutto cosa ci farei io da qui ai prossimi mesi se gestissi la piattaforma di un merchant mid-market.
Cosa rende la 2.4.4 diversa da una minor qualsiasi
Il punto centrale è la finestra di supporto. Adobe ha impostato la 2.4.4 come una release pensata per durare: una linea “quality and security” con un ciclo di manutenzione pluriennale, cioè con patch di sicurezza e correzioni che continueranno ad arrivare ben oltre l’uscita delle minor successive. Non è la solita release che dopo dodici mesi ti ritrovi già in coda per essere superata.
Nella pratica quotidiana questa è una differenza enorme. Chi lavora con Adobe Commerce sa che il vero costo non è aggiornare una volta: è aggiornare di continuo. Ogni minor porta con sé nuove dipendenze, moduli deprecati, estensioni di terze parti da riallineare, regressioni da cacciare in staging. Una release con supporto esteso rompe questo ciclo: ti dà un punto fermo su cui puoi restare più a lungo senza andare fuori supporto, e senza sentirti in colpa.
Per me è esattamente questo il valore strategico della 2.4.4. Non le funzionalità che porta, ma il fatto che ti offre un posto dove stabilizzarti.
L’altra metà della storia: PHP 8.1
C’è un secondo motivo, meno raccontato ma altrettanto importante. La 2.4.4 sposta il baseline dello stack tecnologico. Il salto più rilevante è il supporto a PHP 8.1, con l’abbandono progressivo delle versioni più vecchie che ormai stanno uscendo dal loro ciclo di vita ufficiale.
Questo cambia la natura dell’aggiornamento. Passare da una 2.4.x a un’altra 2.4.x è, il più delle volte, un lavoro di manutenzione. Passare a PHP 8.1 è invece un upgrade major di stack: tocca l’ambiente, non solo l’applicazione. Significa verificare che ogni modulo custom e ogni estensione di terze parti sia compatibile, che i servizi collegati reggano, che il codice scritto anni fa non usi costrutti che 8.1 non perdona più.
Ed è qui che la finestra di supporto esteso e il salto di PHP si incastrano in modo, secondo me, quasi perfetto. Se devo comunque affrontare la fatica di portare tutto su PHP 8.1, allora tanto vale farlo una volta sola e atterrare su una release che poi mi tiene stabile per anni, invece di ripetere lo stesso stress a ogni minor.
Un errore che ho visto fare più volte
Ho in mente il caso di un merchant fashion, un multi-store da qualche decina di milioni di GMV, che negli ultimi due anni ha inseguito ogni minor appena usciva. Ogni volta: settimane di lavoro, regressioni sul checkout, un’estensione di pagamento da ricompilare. Ogni volta il team esausto, e poche settimane dopo la minor successiva già in vista. Un tapis roulant.
Il problema non era la competenza del team, che era ottima. Era la strategia di upgrade: aggiornare per non restare indietro, senza un punto d’arrivo. Una release con supporto esteso è la risposta a questa trappola. Ti permette di dire: “atterriamo qui, e da qui applichiamo solo security patch per un bel po’”. È una scelta che libera tempo e budget per cose che generano valore vero, tipo la conversion rate o l’integrazione con l’ERP, invece di bruciarli in manutenzione difensiva.
Come pianificherei io l’upgrade
Non tratterei la 2.4.4 come una patch da schedulare in una serata. La tratterei come un piccolo progetto, con quattro fasi.
- Audit delle dipendenze prima di tutto. Prima ancora di parlare di date, mapperei ogni estensione di terze parti e ogni modulo custom, verificando la compatibilità dichiarata con PHP 8.1 e con la 2.4.4. Le estensioni commerciali sono spesso il collo di bottiglia: se un vendor non ha ancora rilasciato la versione compatibile, quello diventa il vincolo che detta i tempi, non il tuo calendario.
- Ambiente di staging identico alla produzione. Non “simile”: identico, PHP 8.1 incluso. La maggior parte delle brutte sorprese su Adobe Commerce nasce da differenze tra staging e produzione che nessuno aveva notato.
- Testing sui percorsi che fanno fatturato. Checkout, pagamenti, calcolo tasse e spedizioni, sincronizzazione ordini verso l’ERP, indicizzazione. Qui non mi affido solo ai test automatici: aggiungo passaggi manuali sui flussi critici, perché è lì che PHP 8.1 fa emergere i costrutti deprecati nel codice più vecchio.
- Finestra di rilascio lontana dai picchi. Un upgrade major non si mette in produzione a ridosso di una campagna o della stagione forte.
La mia raccomandazione sui tempi
Sarò netto, perché è il tipo di domanda che mi arriva più spesso in questo periodo. Non partirei il giorno stesso della GA. Le prime settimane dopo il rilascio di una release così strutturale servono a far emergere gli spigoli, sia lato Adobe sia lato vendor delle estensioni.
Quello che farei subito, però, è l’audit delle dipendenze e la preparazione dello staging su PHP 8.1. Quel lavoro non richiede che la 2.4.4 sia già installata in produzione, e ti fa arrivare pronto. Poi pianificherei l’upgrade vero in una finestra tranquilla, lasciando passare qualche settimana dalla GA per far decantare le prime patch correttive.
Chi è ancora su versioni davvero vecchie ha un motivo in più per muoversi ora: prima si prepara il terreno, meno traumatico sarà il salto. Ma “muoversi ora” significa pianificare, non installare di corsa.
La 2.4.4, in fondo, non è interessante per quello che aggiunge. È interessante perché ti offre qualcosa di raro in questo ecosistema: un punto fermo. E in una piattaforma dove tutto sembra sempre in movimento, un punto fermo vale parecchio.
Domande frequenti
Perché la 2.4.4 viene definita una release strategica?
Perché ha una finestra di supporto più lunga rispetto a una minor ordinaria: è una release “quality and security” con manutenzione pluriennale. Questo la rende un buon punto su cui stabilizzarsi, riducendo la necessità di aggiornare a ogni release successiva.
La 2.4.4 richiede PHP 8.1?
La 2.4.4 sposta il baseline dello stack e introduce il supporto a PHP 8.1, abbandonando progressivamente le versioni più vecchie. Per questo l’aggiornamento va trattato come un upgrade major di stack, non come una semplice patch applicativa.
Conviene aggiornare il giorno stesso della GA?
Secondo me no. Meglio avviare subito l’audit delle dipendenze e preparare uno staging su PHP 8.1, ma pianificare l’upgrade in produzione qualche settimana dopo la GA, in una finestra lontana dai picchi di traffico.
Qual è il rischio maggiore in un upgrade a 2.4.4?
La compatibilità delle estensioni di terze parti e dei moduli custom con PHP 8.1. È spesso il vendor di un’estensione commerciale a dettare i tempi: se non ha ancora rilasciato una versione compatibile, quel vincolo determina il calendario dell’intero progetto.
Chi sono. Sono Fabio Canovi, mi occupo di Magento e Adobe Commerce dal 2011 e sono tra i primi professionisti in Italia ad aver ottenuto la certificazione Adobe Commerce. Su questo blog condivido la mia lettura da insider dell’ecosistema: cosa succede nella piattaforma e cosa significa concretamente per chi vende online.