Où en est le support de Symfony 2.8 et 3.4 ?
| Critère | Symfony 2.8 | Symfony 3.4 |
|---|---|---|
| Sortie | novembre 2015 | novembre 2017 |
| Fin des correctifs de bugs | novembre 2018 | novembre 2020 |
| Fin des correctifs de sécurité | novembre 2019 | novembre 2021 |
| PHP minimum | 5.3.9 | 5.5.9 |
Statuts vérifiés le 08/11/2026 sur les pages officielles de version.
Les ruptures à traiter en premier
Le chemin de migration, étape par étape
Chaque étape se termine sur une version sans dépréciation avant la majeure suivante : c’est la seule montée que la promesse de rétrocompatibilité de Symfony couvre. Avant de lancer le chantier, auditer la dette technique avec Bear Scan chiffre la dette qui ralentira chaque étape.
Côté outillage, Rector 2 ne s’appuie plus sur un set par version : withComposerBased(symfony: true) applique les règles de la version de Symfony installée, et withAttributesSets(symfony: true) convertit les annotations en attributs. On relance Rector après chaque montée de composer.json (configuration testée sur un passage vers Symfony 8).
Avant de quitter Symfony 2.8
PHP minimum : 5.3.9
- BloquantFormTypeInterface::getName() est déprécié : il faut passer à getBlockPrefix() ou aux noms de classe (FQCN) pour les types de formulaire.source
- À traiterL'option cascade_validation des formulaires est dépréciée au profit de l'option constraints avec la contrainte Valid.source
- À traiterLes scopes du conteneur (Definition::setScope(), ContainerBuilder::getScopes()) sont dépréciés ; le nouveau drapeau shared les remplace.source
- À traiterAbstractVoter est déprécié : les voters doivent étendre la classe Voter.source
- MineurLe paramètre session.cookie_httponly vaut désormais true par défaut : à vérifier si du JavaScript lit le cookie de session.source
Pièges rencontrés en migration
- La 2.8 sert de palier de nettoyage : tout ce qu'elle déprécie est supprimé en 3.0. Corriger les dépréciations (formulaires, scopes, voters) avant de monter.source
Symfony 3 (3.0, 3.1, 3.2, 3.3 et 3.4)
PHP minimum : 5.5.9
- Bloquant · 3.0Le composant Locale est supprimé : migrer vers Intl (par exemple Intl::getLanguageBundle()).source
- Bloquant · 3.0Form::bind() et isBound() sont supprimées : utiliser submit(), isSubmitted() ou handleRequest().source
- Bloquant · 3.0Le service request est supprimé : injecter request_stack et appeler getCurrentRequest().source
- Bloquant · 3.2Appeler isValid() sur un formulaire non soumis est déprécié : écrire isSubmitted() && isValid().source
- Bloquant · 3.2doctrine/annotations n'est plus une dépendance directe de FrameworkBundle : l'ajouter explicitement dans composer.json si vous utilisez des annotations.source
- Bloquant · 3.3L'autowiring par types implémentés est déprécié (retiré en 4.0) : déclarer des alias ou nommer les services par FQCN.source
Pièges rencontrés en migration
- Aucune couche de compatibilité : passer de 2.8 à 3.0 sans avoir éliminé toutes les dépréciations casse le code immédiatement. Les logs de dépréciation de la 2.8 sont le point de départ.source
- Les routes en YAML ou annotations utilisant pattern, _method ou _scheme doivent toutes être réécrites.source
- Version non LTS maintenue environ 14 mois : ne pas s'y arrêter, c'est un simple pas vers la 3.4 LTS.source
À lire sur le blog : Sécuriser votre app Symfony en 30 minutes : checklist OWASP
Ce que Symfony 3.4 vous apporte
- 3.0 : Mêmes nouveautés que la 2.8 (publiées en même temps), sans la couche de compatibilité : la 3.0 est la 2.8 débarrassée de toutes ses dépréciations.source
- 3.1 : Le composant Cache implémente PSR-6 et pose les bases du cache applicatif de Symfony.source
- 3.2 : Le Cache gagne NullAdapter, PhpFilesAdapter, PdoAdapter et TagAwareAdapter (invalidation par tags), plus la commande cache:pool:clear.source
- 3.3 : L'option autoconfigure et la découverte de services PSR-4 réduisent la configuration des services à quelques lignes.source
- 3.4 : Le nouveau composant Lock fournit des verrous (mutex) pour sérialiser des traitements concurrents.source
Combien coûte cette migration ?
Petite application
100 fichiers PHP, 15 entités, 2 bundles maison
5 150 € HT
Application métier
400 fichiers PHP, 60 entités, 6 bundles maison
20 260 € HT
Plateforme
1 200 fichiers PHP, 150 entités, 15 bundles maison
70 210 € HT
Exemples de la grille Bear Upgrade pour Symfony 2 → 3 (tests à 20 %, sans PHPStan ni CI), pas des devis : le prix ferme est fixé au cadrage.
Pour confier la migration à Bear Upgrade, Rector tourne d’abord en dry-run sur les transformations mécaniques, Claude Code traite les cas que Rector ne couvre pas, puis un développeur senior relit chaque Merge Request. Votre équipe veut reprendre la main ensuite ? Pensez à former votre équipe à Claude Code. Exemple concret : la migration Symfony d’un e-commerce bordelais, et après la migration, la maintenance des versions garde le socle à jour.
Sur une base aussi ancienne, l’audit d’abord : Bear Scan mesure tests, dépendances abandonnées et code mort avant de fixer le prix de la migration.
Questions fréquentes
Oui : une fois les dépréciations de Symfony 2.8 corrigées, le passage à Symfony 3.4 se fait sans réécriture, en mettant à jour composer.json et la configuration.
Symfony 3.4 exige PHP 5.5.9 au minimum, contre PHP 5.3.9 pour Symfony 2.8. La montée de PHP fait partie du chemin et se prépare avec Rector.
Sur la grille Bear Upgrade, une petite application revient à 5 150 € HT, une application métier à 20 260 € HT et une plateforme à 70 210 € HT (tests à 20 %, sans PHPStan ni CI). Le prix ferme est fixé au cadrage, après lecture du code.
Symfony 2.8 ne reçoit plus de correctifs de sécurité depuis novembre 2019 (fin des correctifs de bugs : novembre 2018).