Node.js passe au rythme annuel. Planifiez vos mises à jour

Node.js change sa façon de publier les versions majeures, et le modèle mental que chaque équipe backend a utilisé depuis dix ans disparaît. À partir de la version 27, le projet passe de deux versions majeures par an à une seule. La règle pair-impair, selon laquelle les versions impaires avaient une courte durée de vie et les versions paires devenaient LTS (support à long terme), est abandonnée. Chaque version annuelle deviendra désormais LTS.

La nouvelle cadence est simple. Une version majeure sort chaque avril, avec promotion LTS en octobre suivant. Les numéros de version correspondent à l'année civile de la première phase Current d'une version : 27.0.0 arrive en avril 2027, 28.0.0 en 2028, et ainsi de suite. Il existe également un nouveau canal Alpha de six mois, d'octobre à mars, où les changements non rétrocompatibles (semver-major) sont autorisés et où l'équipe de publication exécute les suites de tests des packages populaires contre la version à venir via CITGM. Node.js 26, la branche publiée en mai dernier, est la dernière sous l'ancien modèle. L'Alpha de Node 27 ouvre en octobre.

Qu'est-ce que cela signifie concrètement si vous déployez Node en production ? Moins que le titre ne le suggère, et c'est précisément l'objectif.

Si votre équipe s'ancre déjà sur LTS et ignore la branche Current, presque rien ne change hormis le calcul des versions. Vous mettez toujours à jour environ tous les deux ans et bénéficiez toujours d'environ 30 mois de support par branche. Nous avons géré de nombreux projets d'entreprise à long terme de cette façon, notamment les travaux de conformité suisses, où « ennuyeux et prévisible » est une fonctionnalité, pas une plainte. Supprimer la règle pair/impair efface surtout un folklore que les nouvelles recrues avaient toujours du mal à comprendre.

Le vrai changement est le canal Alpha, et il s'adresse à un groupe que la plupart des équipes oublient d'inclure : quiconque maintient une bibliothèque, un SDK ou un package interne partagé. Pendant des années, les versions impaires étaient là où les ruptures apparaissaient en premier, et presque personne ne testait contre elles. Maintenant, il existe une fenêtre explicite de six mois, d'octobre à mars, pour détecter un changement non rétrocompatible avant qu'il n'atteigne le LTS dont dépendent vos clients. D'après notre travail PHP et Docker, nous avons vu le même scénario dans d'autres écosystèmes : la rupture est rarement dans le framework lui-même, elle se trouve dans une dépendance transitive que personne n'a testée contre la bêta. Un canal Alpha annuel, c'est le projet qui vous donne une date fixe pour le découvrir.

Voici la partie pratique. Ajoutez un job Node Alpha à votre CI dès maintenant, avant octobre, même s'il est autorisé à échouer. Une seule entrée de matrice qui exécute votre suite de tests sur le dernier Node Alpha et signale les résultats sans bloquer le build. Cela ne vous coûte qu'un job supplémentaire, et cela transforme « notre application est cassée sur le nouveau Node » en ticket que vous ouvrez en novembre plutôt qu'en incendie que vous combattez au printemps suivant. Si vous publiez des packages, ce n'est pas facultatif. C'est ainsi que vous évitez d'être la dépendance qui casse tout le monde.

Un mot sur le réflexe de mise à jour que cela encourage. Une version majeure annuelle prévisible, c'est bien, mais « prévisible » peut endormir les équipes en mode pilote automatique. Nous le voyons aussi dans le mobile. Dans nos projets iOS et Android natifs, une version annuelle du système d'exploitation habitue les équipes à s'attendre à une mise à jour sans accroc, jusqu'à l'année où ce n'est pas le cas. Traitez chaque version majeure de Node comme une vraie migration avec sa propre passe de tests, pas comme un simple cachet d'approbation. La fenêtre Alpha existe précisément pour que la version d'avril puisse être ennuyeuse.

Il y a un angle sécurité qui mérite d'être mentionné. Des calendriers de support plus clairs signifient moins d'équipes exécutant accidentellement un runtime en fin de vie parce qu'elles avaient perdu de vue quelle branche était « paire » et laquelle était une impasse. Lors de nos missions de pentesting, une version de Node hors support est l'une des constatations les plus fréquentes, généralement un ancien service que personne ne maintient plus. Chaque branche devenant LTS, avec une horloge nette de 30 mois, transforme « sommes-nous sur un runtime supporté ?» en question à réponse par oui ou non plutôt qu'en organigramme. Ajoutez cette date de fin de vie dans votre outil de suivi des dépendances dès aujourd'hui.

Ce à quoi je reviens sans cesse : Node admet que la plupart des équipes n'ont jamais utilisé la cadence de publication telle qu'elle avait été conçue. Une version majeure par an, toutes supportées, les ruptures détectées tôt grâce au canal Alpha. C'est moins astucieux et plus honnête, et après des années à expliquer le pair/impair aux clients, je préfère l'honnêteté.

Si maintenir une flotte de services Node sur des versions de runtime supportées et bien testées vous parle, parlons-en.