Par les équipes de Symfony, on apprend qu'un nouveau lot de versions de maintenance vient de débarquer: Symfony 6.4.45, 7.4.18 et 8.1.6 sont dispo depuis le 6 septembre! Au programme, le combo classique bugs corrigés + durcissement sécurité, saupoudré de plus de 190 pull requests fusionnées en une seule semaine de dev. Du Symfony à débit industriel, comme on l'aime (et comme nos CI vont probablement le regretter dès ce matin).
Pourquoi trois branches d'un coup?
On a parfois tendance à l'oublier, mais Symfony maintient en parallèle plusieurs versions LTS et stables — c'est tout l'intérêt d'un framework qui prend son cycle de support au sérieux (merci SensioLabs, bisous). La 6.4 reste la LTS historique pour ceux qui n'ont pas encore migré, la 7.4 est la LTS actuelle qui équipe la majorité des projets en prod, et la 8.1 file déjà vers ses propres itérations. Quand Symfony release trois branches le même jour, c'est rarement anodin: soit un patch de sécurité transversal a été backporté, soit une régression touchait plusieurs versions. Là, à en croire le billet officiel, c'est un peu des deux!
Sous le capot: ce qu'on doit vraiment surveiller
Les renforcements de sécurité inclus dans ce cycle méritent qu'on s'y attarde trente secondes avant de relancer la prod. Personne n'a envie de devoir expliquer à un client pourquoi son app tourne encore sur un Symfony d'il y a six mois (si, vous avez déjà vécu cette scène, avouez-le franchement). Un composer update symfony/* plus tard, et on respire — enfin, jusqu'à la prochaine CVE, évidemment. C'est aussi pour ça que la branche 8.1 reste scrutée de près: c'est elle qui fixera les standards de sécurité pour les mois à venir, et chaque patch rétroporté compte double pour l'écosystème.
Et maintenant, on fait quoi?
Pour les devs qui maintiennent plusieurs projets (à peu près tout le monde dans la communauté, soyons honnêtes), le réflexe à avoir est de vérifier la matrice de compatibilité de vos bundles avant de pousser le bump. Certains packages tiers mettent parfois quelques jours à publier leurs propres releases alignées sur les nouvelles versions mineures — et là, c'est le drame dans le composer.lock. Alors on procède branche par branche, on teste, et surtout — surtout! — on ne merge pas un vendredi à 17h (la règle d'or, gravée dans le marbre du temple PHP). Et vous, vous avez déjà migré un projet de la 6.4 vers la 7.4, ou vous attendez sagement la 8.1 pour sauter le pas? Le débat est ouvert, on a hâte de lire vos retours de terrain!