Chapitre 1.2 — Histoire & versions : le cycle, les LTS, la promesse de BC

Partie 1 : Découvrir Symfony — Chapitre 2/5 Version de référence : Symfony 7.4 LTS (novembre 2025, PHP 8.2+).

⏱️ TL;DR

• Symfony sort une version mineure tous les 6 mois (mai et novembre) et une version majeure tous les 2 ans (en novembre).
• La dernière mineure d’une majeure (X.4) est une LTS, et elle sort le même jour que la majeure suivante X+1.0. Donc 7.4 LTS et 8.0 sont sortis ensemble en novembre 2025.
• 8.0 ≠ nouvelles fonctionnalités : c’est 7.4 débarrassée du code déprécié. Écrire du 7.4 sans API dépréciée = écrire du code déjà compatible 8.x.
• Support : une version standard = ~8 mois de correctifs + ~14 mois de sécurité ; une LTS = 3 ans de correctifs + 4 ans de sécurité. D’où notre choix de la 7.4 LTS.
• La promesse de rétrocompatibilité (BC promise) garantit que votre code ne casse pas à l’intérieur d’une majeure ; les fonctions obsolètes sont dépréciées (signalées) avant suppression.
• Pour un dev Next.js : c’est l’anti-npx create-next-app qui casse à chaque majeure. Ici, la montée de version est un non-événement.

🎯 Objectifs

• Comprendre le calendrier de sortie de Symfony et savoir lire symfony.com/releases .
• Distinguer version standard et version LTS, et leurs durées de support.
• Expliquer pourquoi 8.0 est sorti en même temps que 7.4 et ce que ça implique pour votre code.
• Comprendre le mécanisme de dépréciation et la BC promise, et savoir détecter les dépréciations.
• Justifier en une phrase pourquoi ce cours cible la 7.4 LTS.

1. Un calendrier suisse (littéralement prévisible)

Contrairement à beaucoup de projets qui sortent « quand c’est prêt », Symfony a un calendrier fixe, annoncé des années à l’avance :

• Une version mineure tous les 6 mois : en mai et en novembre. Exemples : 7.1 (mai 2024), 7.2 (nov. 2024), 7.3 (mai 2025), 7.4 (nov. 2025).
• Une version majeure tous les 2 ans, toujours en novembre : 6.0 (nov. 2021), 7.0 (nov. 2023), 8.0 (nov. 2025).
• Chaque majeure a exactement 5 mineures : X.0, X.1, X.2, X.3, X.4. La dernière (X.4) est la LTS.

⚠️ Piège : ne confondez pas « mineure » au sens Symfony et « mineure » au sens SemVer strict. Chez Symfony, une mineure (7.2 → 7.3) peut ajouter des fonctionnalités et déprécier (mais jamais supprimer ni casser). Une majeure (7.4 → 8.0) supprime ce qui était déprécié. C’est du SemVer, mais avec une discipline de dépréciation très stricte.

2. Le coup de génie : X.4 LTS et X+1.0 le même jour

Voici le point qui surprend tout le monde et qu’il faut vraiment intégrer :

La dernière mineure d’une majeure (X.4, la LTS) et la première mineure de la majeure suivante (X+1.0) sortent le même jour et ont exactement les mêmes fonctionnalités. La seule différence : X+1.0 a supprimé tout le code déprécié que X.4 conserve encore.

Conséquence pratique, et c’est fondamental pour ce cours :

Si vous écrivez du 7.4 sans jamais utiliser d’API dépréciée, votre code fonctionne tel quel sur 8.0. Migrer de 7.4 à 8.0 revient alors à… ne rien changer.

C’est pourquoi une règle de rédaction de ce cours est : on n’utilise jamais d’API dépréciée. Vous apprenez donc, sans effort supplémentaire, du code 8.x-ready.

💡 Pour un dev Next.js : imaginez que next@14.last et next@15.0 sortent le même jour, avec les mêmes features, la seule différence étant que la 15.0 retire les API que la 14 marquait « deprecated ». Vous coderiez « sans warnings » en 14 et seriez automatiquement prêt pour la 15. C’est exactement ça — sauf que côté JS, ça n’existe pas.

3. Standard vs LTS : lequel choisir, et pourquoi 7.4

Toutes les versions ne se valent pas côté durée de support :

Une version standard est vite remplacée : 8.0 (nov. 2025) n’a plus de correctifs de bugs dès ~juillet 2026, au profit de 8.1. À l’inverse, 7.4 LTS est maintenue jusqu’à ~novembre 2028 (bugs) et ~novembre 2029 (sécurité).

Pour un cours — comme pour une application de production ou une mission freelance — on veut une base stable et longtemps supportée. D’où :

Ce cours cible Symfony 7.4 LTS. C’est la dernière LTS, la mieux supportée, et — grâce au point du §2 — apprendre la 7.4 « propre », c’est apprendre l’équivalent de la 8.x. (Le raisonnement complet est consigné dans l’ADR 0001  du dépôt.)

⚡ Depuis Symfony 5 : votre dernier repère, Symfony 5, avait aussi sa LTS : 5.4 (nov. 2021), encore supportée en sécurité jusqu’à fin 2025. Beaucoup d’entreprises sont passées de 5.4 LTS → 6.4 LTS → 7.4 LTS en sautant les versions intermédiaires. Ce « saut d’LTS en LTS » est une stratégie de maintenance très courante que vous rencontrerez en mission.

4. Tableau des versions et prérequis PHP

Retenez : toute la lignée 7.x exige PHP 8.2 minimum. Dans ce cours, on installera PHP 8.4 (dernière version stable du langage), car rien n’empêche d’utiliser un PHP plus récent que le minimum — au contraire, on profite ainsi des dernières nouveautés du langage (cf. Partie 2).

📚 Aller plus loin : la page officielle symfony.com/releases  affiche en temps réel les versions maintenues, avec un diagramme de Gantt des supports. À mettre en favori : c’est la source de vérité pour savoir « telle version est-elle encore supportée ? ».

5. La promesse de rétrocompatibilité (BC promise)

C’est l’engagement qui fait la réputation de Symfony. Formellement :

À l’intérieur d’une branche majeure (toute la 7.x), le code public de Symfony ne change pas de comportement de façon cassante. Ce qui doit disparaître est d’abord déprécié, puis supprimé seulement à la majeure suivante.

Ce que cela protège (le code public) et ce que ça ne protège pas est précisément documenté : Symfony distingue le code « BC-covered » (interfaces, méthodes publiques…) du code interne (marqué @internal, @final) que vous ne devez pas étendre. Tant que vous restez dans le cadre normal d’usage, vous êtes couvert.

5.1 Comment une dépréciation se manifeste

Quand vous utilisez une API dépréciée, Symfony ne casse rien mais émet un avertissement (E_USER_DEPRECATED). Vous les voyez :

• dans la barre de débogage et le profiler (un onglet compte les dépréciations de la page) ;
• dans les logs (canal deprecation) ;
• dans la sortie des tests PHPUnit (le pont Symfony fait échouer le build si des dépréciations apparaissent — configurable).

L’objectif : vous donnez toute une version majeure (jusqu’à 2 ans) pour remplacer une API dépréciée, guidé par des messages explicites (« utilisez Y à la place de X »).

⚠️ Piège : « déprécié » ne veut pas dire « ça ne marche plus ». Beaucoup de débutants paniquent en voyant des avertissements de dépréciation sur un projet qui tourne parfaitement. C’est normal : le code fonctionne, on vous prévient juste qu’il faudra le mettre à jour avant la prochaine majeure. Traitez les dépréciations comme une todo-list de migration, pas comme des erreurs.

5.2 Migrer, en pratique

La recette d’une montée de version Symfony réussie tient en deux temps :

1. Sur votre version actuelle, éliminez toutes les dépréciations (le profiler et les tests vous les listent). Votre code devient « propre ».
2. Passez à la majeure suivante : comme il ne reste plus rien de déprécié, il n’y a (quasi) rien à changer.

C’est la raison profonde pour laquelle on écrit « sans dépréciation » dès le départ dans ce cours : on se met dans les conditions d’une migration indolore.

6. Récapitulatif : pourquoi 7.4 LTS est le bon choix pour vous

• Support long (bugs jusqu’à ~2028, sécurité jusqu’à ~2029) → un cours et des projets qui ne périment pas dans six mois.
• Équivalence fonctionnelle avec 8.x → vous n’apprenez rien « en retard » ; du 7.4 propre = du 8.x.
• Version dominante en entreprise/freelance en 2026 → ce que vous croiserez réellement en mission.
• PHP 8.2+ → vous profitez de tout le PHP moderne (Partie 2) sans traîner un vieux langage.

✏️ Exercices

Exercice 1. Un collègue affirme : « Il faut passer en Symfony 8.0, c’est la dernière, la 7.4 est déjà dépassée. » Corrigez-le avec les bons arguments.

Exercice 2. Vous êtes en Symfony 7.2 et le profiler signale 30 dépréciations. L’application fonctionne. Est-ce urgent ? Que faites-vous, et pourquoi, avant d’envisager la 8.0 ?

Exercice 3. Sans consulter le site, dites approximativement quand sortiront Symfony 8.2 et 8.4, et laquelle des deux sera une LTS.

🧠 Quiz de révision

Prochain chapitre : 1.3 — L’écosystème — Composer, Packagist, Flex & recipes, les bundles, API Platform, Symfony UX et la communauté.