Ten sam feature set, inna umowa z czasem
Pod koniec 2025 Symfony wypuściło 7.4 i 8.0 jednocześnie. Obie linie mają te same funkcje. 7.4 zostawia warstwę deprecacji i dostaje LTS. 8.0 czyści stary kod i żyje krócej, za to trzyma Cię bliżej kolejnych minorów.
W 2026 pytanie nie brzmi „która wersja jest nowocześniejsza”. Brzmi: czy chcesz spokojne trzy lata poprawek, czy ciągły dopływ feature’ów.
Co daje Symfony 7.4 LTS
7.4 wymaga PHP 8.2+. Bugfixy lecą do listopada 2028, security do listopada 2029. Dla firm z długim cyklem release’ów i audytami to często wystarczający argument.
Przy okazji LTS dostało rzeczy, które w codziennej pracy czuć od razu:
- XML w konfiguracji jest deprecated. YAML i PHP zostają.
- Lepsze schematy JSON dla YAML (serwisy, routing, validation, serialization), więc IDE mniej milczy przy literówkach.
- UUID v7 jako domyślny w komponencie UUID. Lepsze indeksowanie w bazach przy dużej liczbie insertów.
- Cache w HTTP Client zgodny z RFC 9111, gdy wołasz zewnętrzne API.
Jeśli siedzisz na 6.4 LTS, 7.4 jest naturalnym celem migracji przed końcem wsparcia 6.4.
Kiedy brać Symfony 8.x
8.0 wymaga PHP 8.4+. Nie ma deprecacji z 7.4, więc upgrade z brudnego 7.3 potrafi zaboleć, jeśli wcześniej je ignorowałeś. Zyskujesz krótszą ścieżkę do 8.1, 8.2 i dalej, bez czekania na kolejne LTS w listopadzie 2027.
Bierz 8.x, gdy:
- zespół aktualizuje się co kilka miesięcy,
- i tak celujesz w PHP 8.4 albo 8.5,
- chcesz nowe rzeczy z minorów, a nie tylko security patche,
- masz zielone testy i budżet na sprzątanie deprecacji teraz, nie „kiedyś”.
Deprecacje, które warto ogarnąć przed skokiem
Najgłośniejsza zmiana to odejście od XML. Bundle’e i stare projekty lubią mieć services.xml oraz routing w XML. Symfony daje narzędzia do konwersji, ale i tak warto przejść plik po pliku, a nie hurtem w jednym PR-ze na 400 plików.
Drugi klasyczny temat to $request->get(). Explicit bags (query, request, attributes) są czytelniejsze i mniej magiczne. W większym kodzie to setki drobnych poprawek, więc lepiej zbierać je wcześniej na 7.3/7.4 niż w noc przed cutoverem na 8.0.
Co wybrać w Q3 2026
Nowa aplikacja greenfield na PHP 8.4+: idź w 8.x, jeśli zespół lubi trzymać się current. Produkt enterprise z rzadkimi release’ami: 7.4 LTS i spokój do 2028/2029. Projekt na 6.4: najpierw do 7.4 z wyzerowanymi deprecacjami, potem decyzja czy od razu 8.x, czy zostajesz na LTS.
Wersję wybieraj po tym, jak często deployujesz i ile kosztuje Was jeden duży upgrade w roku.