Node.js abbandona il modello pari-dispari. Ecco come pianificare gli aggiornamenti adesso.

Node.js sta cambiando il modo in cui rilascia le versioni major, e il modello mentale che ogni team backend ha utilizzato per un decennio sta scomparendo. A partire dalla versione 27, il progetto passa da due rilasci major all'anno a uno solo. La regola pari-dispari, in cui i rilasci con numero dispari avevano vita breve e quelli con numero pari diventavano long-term support, viene abbandonata. Ogni rilascio annuale diventerà ora LTS.

Il nuovo ritmo è semplice. Un major arriva ogni aprile, con la promozione a LTS il seguente ottobre. I numeri di versione si allineano con l'anno solare della prima fase Current di un rilascio, quindi 27.0.0 arriva ad aprile 2027, 28.0.0 nel 2028 e così via. C'è anche un nuovo canale Alpha di sei mesi, da ottobre a marzo, in cui sono consentite modifiche breaking (semver-major) e il team di rilascio esegue le suite di test dei pacchetti più diffusi rispetto alla versione in arrivo tramite CITGM. Node.js 26, la linea rilasciata lo scorso maggio, è l'ultima sotto il vecchio modello. L'Alpha di Node 27 apre questo ottobre.

Cosa significa effettivamente tutto questo se fai girare Node in produzione? Meno di quanto suggerisca il titolo, ed è proprio questo il punto.

Se il tuo team è già fissato sulla LTS e ignora la linea Current, quasi nulla cambia a parte i numeri di versione. Aggiorni comunque circa ogni due anni e ottieni comunque circa 30 mesi di supporto per linea. Abbiamo gestito molti progetti enterprise longevi in questo modo, il lavoro di conformità svizzero in particolare, dove «noioso e prevedibile» è una caratteristica, non una lamentela. Eliminare la regola pari/dispari elimina soprattutto un pezzo di folclore su cui i nuovi assunti inciampavano sempre.

Il vero cambiamento è il canale Alpha, e si rivolge a un gruppo che la maggior parte dei team dimentica di appartenere: chiunque mantenga una libreria, un SDK o un pacchetto interno condiviso. Per anni i rilasci con numero dispari erano quelli in cui i problemi di compatibilità emergevano per primi, e quasi nessuno li testava. Ora c'è una finestra esplicita di sei mesi, da ottobre a marzo, per intercettare una modifica breaking prima che raggiunga la LTS da cui dipendono i tuoi clienti. Dal nostro lavoro con PHP e Docker, abbiamo visto lo stesso film in altri ecosistemi: il problema è raramente nel framework stesso, è in qualche dipendenza transitiva che nessuno aveva testato contro la beta. Un canale Alpha annuale è il progetto che ti consegna una data fissa per scoprirlo.

Ecco la parte pratica. Aggiungi un job Node Alpha alla tua CI adesso, prima di ottobre, anche se è consentito che fallisca. Un singolo entry matrix che esegue la tua suite di test rispetto all'ultimo Node Alpha e riporta i risultati senza bloccare la build. Ti costa un job in più, e trasforma «la nostra app si è rotta sul nuovo Node» in un ticket che apri a novembre invece di un incendio che devi spegnere la primavera successiva. Se pubblichi pacchetti, questo non è un optional. È il modo per evitare di essere la dipendenza che rompe tutto il resto.

Una nota sull'impulso all'aggiornamento che questo incoraggia. Un major annuale prevedibile è una buona cosa, ma «prevedibile» può cullare i team nell'autopilota. Lo vediamo anche nel mobile. Nei nostri progetti iOS e Android nativi, un rilascio annuale del sistema operativo abitua i team ad aspettarsi un aggiornamento senza problemi, fino all'anno in cui non lo è. Tratta ogni Node major come una vera migrazione con il suo specifico ciclo di test, non come un timbro di approvazione automatico. La finestra Alpha esiste esattamente perché il rilascio di aprile possa essere noioso.

C'è un aspetto di sicurezza che vale la pena nominare. Scadenze di supporto più chiare significano meno team che accidentalmente fanno girare un runtime a fine vita perché hanno perso traccia di quale linea fosse «pari» e quale fosse un vicolo cieco. Durante i nostri incarichi di penetration testing, una versione di Node non più supportata è uno dei riscontri più comuni, di solito un vecchio servizio di cui non è responsabile nessuno. Con ogni linea che diventa LTS e un clock pulito di 30 mesi, «siamo su un runtime supportato?» diventa una domanda sì/no invece di un diagramma di flusso. Inserisci quella data EOL nel tuo dependency tracker oggi stesso.

La cosa a cui continuo a tornare: questo è Node che ammette che la maggior parte dei team non ha mai usato il ritmo di rilascio nel modo in cui era stato progettato. Un major all'anno, ognuno supportato, le modifiche breaking intercettate presto tramite Alpha. È meno elegante e più onesto, e dopo anni a spiegare pari/dispari ai clienti, scelgo onesto.

Se mantenere una flotta di servizi Node su versioni runtime supportate e ben testate ti suona familiare, parliamone.