Symfony wersje LTS – cykl wydań i okresy wsparcia
29 października, 2026 | 7 minuty czytania
Symfony wydaje nowe wersje według stałego kalendarza: wersja pośrednia (minor) ukazuje się co sześć miesięcy, w maju i w listopadzie, a wersja główna (major) co dwa lata. Wersje standardowe są wspierane przez 8 miesięcy. Ostatnia wersja każdej gałęzi (X.4) jest wersją LTS z 3 latami poprawek błędów i 4 latami poprawek bezpieczeństwa.
Stan na 28 października 2026. Artykuł jest częścią przewodnika Symfony: kompletny przewodnik po frameworku PHP.
Cykl wydań w pigułce
| Cecha | Wartość |
|---|---|
| Nowa wersja pośrednia | co 6 miesięcy, w maju i w listopadzie |
| Nowa wersja główna | co 2 lata, w listopadzie, razem z wersją X.4 poprzedniej gałęzi |
| Wydań w jednej gałęzi | 5 (X.0–X.4) |
| Wsparcie wersji standardowej | 8 miesięcy (błędy i bezpieczeństwo) |
| Wsparcie wersji LTS | 3 lata poprawek błędów, 4 lata poprawek bezpieczeństwa |
| Aktualna wersja stabilna | 8.1, wsparcie do stycznia 2027 |
| Aktualna wersja LTS | 7.4, wsparcie do listopada 2029 |
| Następna wersja | 8.2, planowana na listopad 2026 |
Jak działa kalendarz wydań Symfony
Symfony stosuje model wydań oparty na czasie (time-based release), a nie na funkcjach. Daty premier są znane z wyprzedzeniem, więc zespoły mogą planować aktualizacje tak samo jak budżet czy sprinty.
Sześć miesięcy pracy nad każdą wersją
Prace nad każdą wersją, zarówno pośrednią, jak i główną, trwają sześć miesięcy i dzielą się na dwie fazy:
- Rozwój (4 miesiące). Do kodu trafiają nowe funkcje i ulepszenia istniejących.
- Stabilizacja (2 miesiące). Obowiązuje zamrożenie funkcji (feature freeze): zespół poprawia błędy, przygotowuje wydanie, a biblioteki, bundle i projekty z ekosystemu Symfony mają czas, żeby się dostosować.
Funkcja, która nie zostanie ukończona na czas albo nie jest wystarczająco stabilna, może zostać wycofana i trafić dopiero do kolejnej wersji. Dzięki temu termin premiery jest dotrzymywany.
Wersje główne i pośrednie
Każda gałąź ma pięć wersji: X.0, X.1, X.2, X.3 i X.4. Nowa wersja główna ukazuje się w tym samym dniu co ostatnia wersja pośrednia poprzedniej gałęzi. W listopadzie 2025 wydano więc jednocześnie Symfony 7.4 i Symfony 8.0. Według tego samego kalendarza w listopadzie 2027 ukażą się Symfony 8.4 LTS i Symfony 9.0.
Wersja główna może podnieść minimalną wymaganą wersję PHP, tak jak Symfony 8.0 podniósł ją do PHP 8.4. W wersji pośredniej zdarza się to tylko wyjątkowo, gdy pomaga rozwiązać istotny problem.
Wydania poprawkowe
Między wersjami pośrednimi regularnie ukazują się wydania poprawkowe, np. 8.1.9 czy 7.4.21. Zawierają wyłącznie poprawki błędów i bezpieczeństwa, bez nowych funkcji, więc można je instalować bez obaw o zgodność. Błąd jest naprawiany w najstarszej wspieranej gałęzi, która go zawiera, a poprawka trafia stamtąd do nowszych wersji.
Co mówi numer wersji: wersjonowanie semantyczne
Symfony numeruje wydania zgodnie z wersjonowaniem semantycznym (SemVer), czyli w formacie GŁÓWNA.POŚREDNIA.POPRAWKA. Każda część numeru informuje, jakiego ryzyka można się spodziewać przy aktualizacji:
| Część numeru | Przykład | Co się zmienia | Ryzyko przy aktualizacji |
|---|---|---|---|
| Główna (major) | 7.4 → 8.0 | Usunięcie przestarzałego kodu, nowe wymagania PHP | Wymaga przygotowania projektu |
| Pośrednia (minor) | 8.0 → 8.1 | Nowe funkcje, nowe oznaczenia deprecated | Niskie, dzięki obietnicy kompatybilności |
| Poprawkowa (patch) | 8.1.8 → 8.1.9 | Wyłącznie poprawki błędów i bezpieczeństwa | Minimalne |
W praktyce sam numer wystarcza, żeby ocenić, czy aktualizację można zrobić rutynowo, czy trzeba ją zaplanować jako osobne zadanie.
Wersje standardowe a LTS
Symfony utrzymuje jednocześnie dwa rodzaje wersji. To świadomy wybór projektu: jedni użytkownicy chcą najnowszych funkcji, inni stabilności na lata.
| Cecha | Wersja standardowa | Wersja LTS |
|---|---|---|
| Które wydania | X.0, X.1, X.2, X.3 | X.4 |
| Poprawki błędów | 8 miesięcy | 3 lata |
| Poprawki bezpieczeństwa | 8 miesięcy | 4 lata |
| Nowe funkcje | co 6 miesięcy, z każdą wersją | brak, gałąź jest zamrożona |
| Czas na aktualizację | 2 miesiące, w których stara i nowa wersja są wspierane równocześnie | kilka lat |
| Aktualizacja do nowszej wersji | łatwiejsza, małe kroki co pół roku | trudniejsza, duży skok między gałęziami |
| Dla kogo | zespoły aktywnie rozwijające aplikację | aplikacje stabilne, z ograniczonym budżetem na utrzymanie |
Oficjalna strona Symfony poleca wersję standardową większości użytkowników. Wersja LTS daje spokój na lata, ale za cenę dużej, jednorazowej migracji, gdy jej wsparcie dobiega końca.
Wyjątek wydłużone wsparcie Symfony 5.4
Symfony 5.4 LTS powinien według standardowego cyklu przestać otrzymywać poprawki bezpieczeństwa w listopadzie 2025. Jego wsparcie bezpieczeństwa zostało jednak wydłużone do lutego 2029, co daje dodatkowy czas projektom, których nie da się szybko przenieść na nowsze wersje. Poprawki błędów dla tej wersji zakończyły się w listopadzie 2024.
Wspierane wersje Symfony i harmonogram
Na dzień 28 października 2026 wspierane są cztery wersje Symfony. Symfony 8.0 przestał być wspierany w lipcu 2026.
| Wersja | Typ | Wydana | Wymaga PHP | Koniec poprawek błędów | Koniec poprawek bezpieczeństwa |
|---|---|---|---|---|---|
| 8.1 | standardowa | maj 2026 | 8.4 | styczeń 2027 | styczeń 2027 |
| 7.4 | LTS | listopad 2025 | 8.2 | listopad 2028 | listopad 2029 |
| 6.4 | LTS | listopad 2023 | 8.1 | listopad 2026 | listopad 2027 |
| 5.4 | LTS | listopad 2021 | 7.2.5 | listopad 2024 | luty 2029 (wydłużone) |
okresy wsparcia wersji Symfony · stan na 28 października 2026
Wykres pokazuje, że Symfony 6.4 LTS za miesiąc przechodzi w tryb samych poprawek bezpieczeństwa. Projekty na tej wersji powinny już planować migrację na Symfony 7.4 LTS.
Najbliższe wydania
| Termin | Wydanie | Uwagi |
|---|---|---|
| listopad 2026 | Symfony 8.2 | wersja standardowa, wymaga PHP 8.4, wsparcie do lipca 2027 |
| maj 2027 | Symfony 8.3 | wersja standardowa, według kalendarza |
| listopad 2027 | Symfony 8.4 LTS i Symfony 9.0 | następna wersja LTS i nowa wersja główna, według kalendarza |
Obietnica kompatybilności wstecznej
Cykl wydań działa dzięki Backward Compatibility Promise. To zobowiązanie zespołu Symfony, że aktualizacja w obrębie jednej wersji głównej, np. z 7.1 do 7.4, nie zepsuje kodu, który korzysta z publicznego API frameworka.
Jak Symfony usuwa stare funkcje
- Oznaczenie jako przestarzałe. Funkcja, którą zespół chce usunąć, dostaje status deprecated w jednej z wersji pośrednich. Nadal działa, ale przy jej użyciu Symfony zgłasza ostrzeżenie widoczne w Profilerze, logach i raportach testów.
- Okres przejściowy. Przestarzała funkcja działa do końca gałęzi, a ostrzeżenie zwykle wskazuje, czym ją zastąpić.
- Usunięcie w wersji głównej. Funkcja znika dopiero w kolejnej wersji głównej.
Z tego wynika najważniejsza zasada aktualizacji: wersja X.0 ma te same możliwości co wersja X−1.4, tylko bez przestarzałego kodu. Symfony 8.0 to więc Symfony 7.4 bez funkcji oznaczonych jako deprecated.
Czego obietnica nie obejmuje
Gwarancja dotyczy publicznego API. Nie obejmuje kodu oznaczonego jako wewnętrzny (@internal) ani funkcji eksperymentalnych, które mogą się zmieniać między wersjami pośrednimi. Jeśli aplikacja korzysta z takich elementów, każdą aktualizację trzeba sprawdzić dokładniej.
Dlaczego Symfony co dwa lata „sprząta” kod
Usuwanie przestarzałych funkcji w każdej wersji głównej nie jest tylko kwestią porządku. Kod utrzymywany wyłącznie dla zgodności wstecznej wymaga dodatkowych warstw pośrednich i warunków, które spowalniają framework i utrudniają jego rozwój. Wersja X.0 jest dzięki temu lżejsza od X−1.4, mimo że ma te same możliwości.
Symfony a wersje PHP
Wersje Symfony i PHP są ze sobą ściśle powiązane, dlatego planując aktualizację frameworka, trzeba patrzeć na oba kalendarze.
- Minimalna wersja PHP rośnie wraz z wersją główną. Symfony 7 wymaga PHP 8.2, a Symfony 8 wymaga PHP 8.4. W obrębie gałęzi wymaganie zwykle się nie zmienia.
- Nowe wydania PHP są zazwyczaj wspierane przez utrzymywane gałęzie Symfony. PHP ukazuje się co roku pod koniec listopada, a zespół Symfony dba o to, żeby wspierane wersje frameworka działały również na nim. Dzięki temu można aktualizować PHP bez zmiany wersji Symfony.
- Koniec wsparcia PHP to też ryzyko. Aplikacja na wspieranej wersji Symfony, ale na PHP bez poprawek bezpieczeństwa, nadal jest narażona. Sprawdź daty wsparcia swojej wersji PHP na php.net/supported-versions.
| Wersja Symfony | Minimalna wersja PHP |
|---|---|
| 8.x | 8.4 |
| 7.x | 8.2 |
| 6.x | 8.1 (6.0: 8.0.2) |
| 5.4 | 7.2.5 |
Którą wersję Symfony wybrać?
Wybór zależy od tego, jak aktywnie aplikacja będzie rozwijana i ile czasu zespół może przeznaczyć na aktualizacje. Poniżej zalecenia dla typowych sytuacji, według stanu z października 2026.
| Sytuacja | Zalecenie |
|---|---|
| Nowy projekt, aktywnie rozwijany | Symfony 8.1, a potem kolejne wersje co pół roku aż do 8.4 LTS w listopadzie 2027 |
| Nowy projekt z małym budżetem na utrzymanie | Symfony 7.4 LTS, wsparcie bezpieczeństwa do listopada 2029 |
| Serwer nie obsługuje jeszcze PHP 8.4 | Symfony 7.4 LTS, który działa od PHP 8.2 |
| Projekt na Symfony 8.0 lub 7.3 | Te wersje nie są już wspierane. Aktualizacja do 8.1 lub 7.4 to zmiana wersji pośredniej, zwykle szybka |
| Projekt na Symfony 6.4 LTS | Zaplanuj migrację na 7.4 LTS. Poprawki błędów kończą się w listopadzie 2026, bezpieczeństwa w listopadzie 2027 |
| Projekt na Symfony 5.4 LTS | Wsparcie bezpieczeństwa trwa do lutego 2029, ale poprawek błędów już nie ma. Migruj etapami: 5.4 → 6.4 → 7.4 |
| Projekt na starszej wersji (4.4 i wcześniejsze) | Brak jakichkolwiek poprawek. Potrzebny jest audyt i plan migracji |
Strategia pośrednia: najpierw nowości, potem LTS
Często sprawdza się podejście mieszane. Projekt startuje na najnowszej wersji standardowej, przez kilka wydań korzysta z nowych funkcji, a gdy ukaże się wersja LTS, zostaje na niej na dłużej. Projekt rozpoczęty dziś na Symfony 8.1 może w ten sposób dojść do Symfony 8.4 LTS i mieć wsparcie do listopada 2031, jeśli 8.4 otrzyma standardowe 4 lata poprawek bezpieczeństwa.
Jeśli potrzebujesz pomocy przy wyborze wersji lub migracji, zobacz nasze usługi Symfony.
Jak sprawdzić i zaktualizować wersję Symfony
Sprawdzenie wersji i dat wsparcia
Najszybciej zrobisz to poleceniem:
php bin/console about
Polecenie pokazuje wersję Symfony oraz daty końca wsparcia i końca życia zainstalowanej gałęzi. Listę wszystkich pakietów Symfony z wersjami wyświetli composer show „symfony/*”.
Znane podatności w zależnościach projektu sprawdzisz poleceniem symfony check:security z Symfony CLI albo composer audit.
Aktualizacja poprawkowa, np. 7.4.20 → 7.4.21
Wystarczy composer update „symfony/*”. Wydania poprawkowe nie zmieniają API, więc to bezpieczna, rutynowa operacja, którą warto wykonywać regularnie.
Aktualizacja pośrednia, np. 7.3 → 7.4
W pliku composer.json zmień wersje pakietów Symfony z 7.3.* na 7.4.*, również w sekcji extra:
„extra”: {
„symfony”: {
„require”: „7.4.*”
}
}
Następnie uruchom composer update „symfony/*” i przejrzyj ostrzeżenia o przestarzałym kodzie. Dzięki obietnicy kompatybilności wstecznej aplikacja powinna działać bez zmian.
Aktualizacja główna, np. 7.4 → 8.0
- Zaktualizuj projekt do ostatniej wersji gałęzi, czyli X.4.
- Usuń wszystkie użycia przestarzałego kodu. Ostrzeżenia znajdziesz w Profilerze, logach i raporcie testów. Część zmian zautomatyzujesz narzędziem Rector z zestawami reguł dla Symfony.
- Sprawdź wymagania PHP. Symfony 8 wymaga PHP 8.4, więc serwer często trzeba zaktualizować wcześniej.
- Zmień wersje w composer.json na nową gałąź i uruchom composer update „symfony/*”.
- Zaktualizuj recipes poleceniem composer recipes:update, które pokaże zmiany w plikach konfiguracyjnych.
- Przeczytaj plik UPGRADE dla nowej wersji (np. UPGRADE-8.0.md w repozytorium Symfony) i uruchom testy.
Szczegóły migracji opisuje artykuł Aktualizacja Symfony między wersjami.
Jak zapisać wersję w composer.json
Sposób zapisania wersji w composer.json decyduje o tym, co zainstaluje composer update:
| Zapis | Co dopuszcza | Kiedy stosować |
|---|---|---|
| 7.4.* | tylko poprawki gałęzi 7.4 | projekty na LTS, które mają pozostać na tej gałęzi |
| ^8.1 | wszystkie wersje 8.x od 8.1 wzwyż | biblioteki i bundle wspierające całą gałąź |
| 8.1.9 | dokładnie jedną wersję | praktycznie nigdy, blokuje poprawki bezpieczeństwa |
W aplikacjach opartych na Symfony Flex wersję wszystkich pakietów Symfony najlepiej kontrolować jednym miejscem, czyli kluczem extra.symfony.require. Flex pilnuje wtedy, żeby żaden pakiet symfony/* nie został zainstalowany w innej gałęzi niż pozostałe.
Ile kosztuje pozostanie na starej wersji
Aktualizacje bywają odkładane, bo „aplikacja działa”. Koszt rośnie jednak z każdym miesiącem, nawet jeśli nie widać go od razu:
- Brak poprawek bezpieczeństwa. Po końcu wsparcia nowo odkryte podatności w frameworku nie zostaną załatane, a informacje o nich są publiczne.
- Zależności przestają wspierać starą wersję. Bundle i biblioteki z czasem wymagają nowszego Symfony lub PHP, więc nawet drobna zmiana w projekcie może zablokować się na konflikcie wersji.
- Problemy z hostingiem i PHP. Stare Symfony często wymusza stare PHP, którego dostawcy hostingu i obrazy Dockera przestają dostarczać.
- Audyty i wymagania klientów. Coraz więcej umów i audytów bezpieczeństwa wymaga wspieranych wersji oprogramowania.
- Rosnący koszt migracji. Każda pominięta wersja główna to kolejna porcja usuniętych funkcji do przepisania. Migracja z 5.4 do 7.4 to w praktyce dwa projekty aktualizacji naraz.
Regularne, małe aktualizacje są niemal zawsze tańsze niż jedna duża migracja po latach zaniedbań.
Jak to wygląda w liczbach, pokazuje opisana wyżej migracja z Symfony 5.2 do 7.4 LTS, która zajęła 160 roboczogodzin.
Odkładanie aktualizacji a bezpieczeństwo aplikacji
Z perspektywy bezpieczeństwa wersja Symfony nie jest kwestią wygody programistów, tylko powierzchni ataku. Poniżej mechanizmy, przez które odkładana aktualizacja zamienia się w realne ryzyko.
Poprawka bezpieczeństwa to publiczna instrukcja dla atakującego
Gdy zespół Symfony publikuje poprawkę, jednocześnie ukazuje się biuletyn bezpieczeństwa (security advisory) z opisem problemu, a zmiana w kodzie jest widoczna w publicznym repozytorium. Dla atakującego to gotowa wskazówka: porównując wersję przed poprawką i po niej, może ustalić, jak wykorzystać lukę w aplikacjach, które jeszcze się nie zaktualizowały. Od tego momentu liczy się czas. Każdy dzień między publikacją poprawki a jej wdrożeniem to okno, w którym podatność jest znana, a aplikacja nadal otwarta.
Po końcu wsparcia poprawek po prostu nie ma
Poprawki bezpieczeństwa trafiają wyłącznie do utrzymywanych gałęzi. Jeśli podatność dotyczy również nieutrzymywanej wersji, np. Symfony 8.0 po lipcu 2026, zespół Symfony jej tam nie naprawi. Zostają wtedy trzy drogi: pilna, nieplanowana migracja pod presją czasu, samodzielne przenoszenie poprawek do starego kodu (kosztowne i podatne na błędy) albo płatne wsparcie rozszerzone, jeśli jest dostępne. Żadna z nich nie jest tańsza od regularnych aktualizacji.
Ryzyko nie kończy się na frameworku
Aplikacja Symfony to dziesiątki pakietów: Twig, Doctrine, klienci HTTP, biblioteki do PDF-ów czy płatności. Stara wersja Symfony blokuje aktualizację wielu z nich, bo nowsze wydania wymagają nowszego frameworka lub PHP. W efekcie projekt utyka na podatnych wersjach zależności, nawet gdy ich poprawki dawno istnieją. To samo dotyczy samego PHP: wersja bez wsparcia nie dostaje poprawek bezpieczeństwa interpretera, a stare Symfony często uniemożliwia przejście na nowszą.
Jakie podatności łata Symfony
Biuletyny bezpieczeństwa Symfony dotyczą zwykle elementów, które przyjmują dane z zewnątrz lub decydują o dostępie:
- uwierzytelnianie i sesje: np. błędy w obsłudze tokenów, sesji lub mechanizmu „remember me”, które mogą prowadzić do przejęcia konta,
- obsługa żądań HTTP: np. niewłaściwe parsowanie adresów i nagłówków, umożliwiające otwarte przekierowania lub obejście reguł dostępu,
- cache HTTP: np. zapisanie w pamięci podręcznej odpowiedzi z danymi innego użytkownika,
- szablony i walidacja danych: np. możliwość wstrzyknięcia kodu (XSS), gdy dane nie są poprawnie zabezpieczane,
- konfiguracja środowiska: np. możliwość wpływania na tryb działania aplikacji z zewnątrz w nietypowych konfiguracjach serwera.
To dokładnie te obszary, w których skutki ataku są najpoważniejsze: wyciek danych osobowych, przejęcie kont administratorów, nieautoryzowane transakcje.
Konsekwencje prawne i biznesowe
RODO wymaga stosowania odpowiednich środków technicznych do ochrony danych osobowych, a podmioty objęte dyrektywą NIS2 muszą zarządzać podatnościami w swoich systemach. Świadome utrzymywanie oprogramowania bez wsparcia bezpieczeństwa trudno uznać za odpowiedni środek, co ma znaczenie przy ocenie incydentu przez organ nadzorczy, ubezpieczyciela czy klienta. Coraz częściej wersje oprogramowania są też weryfikowane w audytach dostawców i testach penetracyjnych przed podpisaniem umowy.
Jak ograniczyć ryzyko w praktyce
Wykrywaj podatności automatycznie. W procesie CI uruchamiaj composer audit lub symfony check:security, które porównują zainstalowane pakiety z bazą znanych podatności. Pakiet roave/security-advisories dodany do zależności deweloperskich blokuje instalację wersji ze zgłoszonymi lukami. Narzędzia takie jak Dependabot lub Renovate same zaproponują aktualizacje w repozytorium.
Subskrybuj biuletyny. Powiadomienia o nowych wydaniach i biuletynach bezpieczeństwa można włączyć na stronie symfony.com/releases. Zespół odpowiedzialny za aplikację powinien dostawać je bezpośrednio.
Ustal stały rytm aktualizacji:
| Rodzaj aktualizacji | Zalecany termin |
|---|---|
| Poprawka bezpieczeństwa (security advisory) | w ciągu kilku dni od publikacji |
| Wydania poprawkowe | co najmniej raz w miesiącu |
| Wersja pośrednia | w ciągu 2 miesięcy, zanim poprzednia straci wsparcie |
| Wersja główna lub migracja między LTS | zaplanowana z wyprzedzeniem, przed końcem poprawek błędów obecnej gałęzi |
Zabezpiecz to, czego aktualizacja nie naprawi. Niezależnie od wersji upewnij się, że produkcja działa w środowisku prod z wyłączonym trybem debugowania, a Profiler i pasek debugowania nie są dostępne publicznie. Udostępniony Profiler ujawnia konfigurację, zapytania do bazy i dane żądań, w tym nagłówki z danymi uwierzytelniającymi. Sekrety przechowuj w Secrets Vault lub zmiennych środowiskowych, a nie w repozytorium.
Jeśli migracja musi poczekać, traktuj to jako zarządzane ryzyko: zapisz datę końca wsparcia, ustal termin migracji i ogranicz ekspozycję aplikacji, np. regułami WAF, ograniczeniem dostępu do panelu administracyjnego czy dodatkowym monitoringiem logów. To rozwiązania przejściowe, a nie zamiennik aktualizacji.
Z audytów Codefia – luka w PHP, której nie da się załatać
W audytach bezpieczeństwa często trafiamy na ten sam scenariusz. Skaner wykrywa podatności nie w kodzie aplikacji, ale w samym interpreterze PHP. Naturalnym krokiem byłoby zainstalowanie wydania z poprawką, tyle że poprawki trafiają wyłącznie do wspieranych wersji PHP, a wszystkie poniżej 8.2 straciły już wsparcie bezpieczeństwa:
| Wersja PHP | Koniec poprawek bezpieczeństwa |
|---|---|
| 7.4 | listopad 2022 |
| 8.0 | listopad 2023 |
| 8.1 | grudzień 2025 |
| 8.2 | grudzień 2026 |
| 8.3 | grudzień 2027 |
| 8.4 | grudzień 2028 |
Jedynym rozwiązaniem jest więc podniesienie PHP. I tu zaczyna się reakcja łańcuchowa: stara wersja Symfony nie jest przystosowana do nowszego PHP, więc aktualizacja interpretera wymusza aktualizację frameworka do wersji z nim kompatybilnej. Ta z kolei wymaga podniesienia Doctrine, Twiga i pozostałych bundli, a te pociągają za sobą zmiany w kodzie aplikacji. Zadanie, które w zgłoszeniu wyglądało na „aktualizację PHP na serwerze”, okazuje się pełną migracją Symfony, taką jak opisana wyżej migracja z 5.2 do 7.4.
Dwa wnioski z tych przypadków:
- Wersja PHP i wersja Symfony to jeden plan, a nie dwa osobne. Aplikacja jest bezpieczna tylko wtedy, gdy wspierane są oba elementy jednocześnie. Planując aktualizację, zawsze sprawdzaj daty wsparcia obu.
- Nie celuj w minimum. PHP 8.2 kończy wsparcie bezpieczeństwa już z końcem 2026 roku, więc migracja „tylko do 8.2” po kilku miesiącach wraca do punktu wyjścia. Przy przejściu na Symfony 7.4 LTS rozsądnym celem jest PHP 8.4, wspierane do końca 2028 roku i wymagane przez Symfony 8, co ułatwi kolejny krok.
Typowe błędy przy planowaniu wersji
- Pozostanie na niewspieranej wersji standardowej. Symfony 8.0 wygląda na nową wersję, ale od lipca 2026 nie dostaje żadnych poprawek. O tym, czy wersja jest bezpieczna, decyduje kalendarz wsparcia, a nie numer.
- Mylenie końca poprawek błędów z końcem wsparcia. Symfony 6.4 LTS kończy poprawki błędów w listopadzie 2026, a poprawki bezpieczeństwa rok później. Po pierwszej dacie znalezione błędy nie będą już naprawiane.
- Odkładanie ostrzeżeń o przestarzałym kodzie. Ostrzeżenia ignorowane przez całą gałąź kumulują się i zamieniają migrację na nową wersję główną w duży projekt. Lepiej usuwać je na bieżąco przy każdej aktualizacji pośredniej.
- Przeskakiwanie wersji głównych. Bezpośrednia migracja z 5.4 na 7.4 jest ryzykowna, bo każda wersja główna usuwa inne przestarzałe funkcje. Bezpieczniej przejść etapami przez 6.4.
- Pomijanie aktualizacji poprawkowych. Poprawki bezpieczeństwa działają tylko wtedy, gdy trafią do projektu. Rutynowe composer update „symfony/*” warto wpisać w stały harmonogram utrzymania.
- Niesprawdzenie zależności przed migracją. Zewnętrzne bundle muszą wspierać nową wersję Symfony. Zanim zaczniesz aktualizację główną, sprawdź ich wymagania w composer.json lub na Packagist.
Z praktyki – migracja z Symfony 5.2 do 7.4 LTS na PHP 8.4
Jeden z ostatnich projektów Codefia dobrze pokazuje, ile kosztuje odkładanie aktualizacji. Aplikacja działała na Symfony 5.2, czyli wersji standardowej, która straciła wsparcie, w tym poprawki bezpieczeństwa, już w lipcu 2021. Przez kilka lat nie otrzymywała więc żadnych łatek, a jednocześnie oddalała się od współczesnego ekosystemu PHP. Celem było przeniesienie jej na Symfony 7.4 LTS i PHP 8.4, połączone z migracją na nową wersję bazy danych.
Łączny nakład pracy: 160 roboczogodzin.
Zakres prac
| Obszar | Co zrobiliśmy |
|---|---|
| Framework i zależności | Podniesienie pakietów Symfony do 7.4 oraz pozostałych zależności do wersji zgodnych z PHP 8.4 i Symfony 7.4, w tym najnowsze Doctrine ORM, Twig i FileManagerBundle |
| Porządki w zależnościach | Usunięcie zbędnych pakietów, m.in. google/cloud-translate (zastąpiony pojedynczym żądaniem HTTP) i jms/serializer-bundle |
| Środowisko | Aktualizacja środowiska deweloperskiego w Dockerze do PHP 8.4 i MariaDB 11.4 LTS |
| Bezpieczeństwo | Przepisanie warstwy Security na nowy system uwierzytelniania Symfony |
| API | Usunięcie API Platform, przepisanie endpointów na zwykłe kontrolery i dostosowanie frontendu |
| Dokumentacja API | Utworzenie dokumentacji od nowa na atrybutach OpenAPI |
| Kod aplikacji | Zamiana anotacji na atrybuty PHP w całej aplikacji, poprawki po przejściu na PHP 8.4, dostosowanie do nowych API bibliotek |
| Refaktoryzacja | Porządki w kodzie z wykorzystaniem możliwości nowszych wersji PHP i Symfony |
| Baza danych | Przygotowanie migracji bazy na nową wersję |
| Jakość | Testy całej aplikacji po zmianach |
Co pochłonęło najwięcej pracy
Skok o dwie wersje główne naraz. Między 5.2 a 7.4 Symfony usunął wiele mechanizmów, na których opierała się aplikacja. Przy regularnych aktualizacjach te zmiany rozłożyłyby się na kilka małych kroków. Tu trzeba było je wprowadzić jednocześnie.
Nowy system Security. Dawny mechanizm uwierzytelniania (Guard) zniknął w Symfony 6.0. Warstwy bezpieczeństwa nie da się zaktualizować przez podmianę wersji, trzeba ją napisać na nowo pod authenticatory, a potem dokładnie przetestować logowanie, uprawnienia i sesje. To obszar, w którym nie można iść na skróty.
Anotacje na atrybuty. Symfony 7 nie obsługuje już anotacji w komentarzach, więc routing, mapowanie Doctrine, walidacja i serializacja musiały przejść na natywne atrybuty PHP. Część zmian da się zautomatyzować narzędziem Rector, ale każdą trzeba sprawdzić.
Decyzja o API Platform. Zamiast aktualizować API Platform przez kilka wersji głównych, uznaliśmy, że przy tym zakresie API prościej i bezpieczniej w utrzymaniu będą zwykłe kontrolery Symfony. Wymagało to dostosowania frontendu i odtworzenia dokumentacji API, ale aplikacja ma teraz mniej zależności i prostszą ścieżkę przyszłych aktualizacji.
Wnioski
- Aktualizacja to dobry moment na odchudzenie projektu. Usunięcie zbędnych pakietów, jak klient Google Cloud Translate używany do jednej operacji, zmniejsza powierzchnię ataku i liczbę zależności do pilnowania w przyszłości.
- Migrację frameworka warto połączyć z infrastrukturą. Aktualizacja PHP, Dockera i bazy danych w jednym, dobrze przetestowanym kroku oszczędza powtarzania testów regresyjnych.
- Najdroższe jest to, co odkładane. Znaczną część z 160 godzin pochłonęło nadrabianie zmian, które przy regularnym utrzymaniu byłyby drobnymi poprawkami co pół roku. Aplikacja na Symfony 7.4 LTS ma teraz poprawki bezpieczeństwa do listopada 2029, a kolejny krok, czyli przejście na 8.4 LTS, będzie znacznie mniejszy.
Zwykle zalecamy migrację etapami, przez każdą wersję LTS. W tym projekcie bezpośredni skok miał sens, bo kluczowe obszary (Security, warstwa API, serializacja) i tak były pisane od nowa, więc etapy pośrednie oznaczałyby podwójną pracę.
FAQ: cykl wydań Symfony
Co oznacza LTS w Symfony?
LTS (Long-Term Support) to wersja z wydłużonym wsparciem: 3 lata poprawek błędów i 4 lata poprawek bezpieczeństwa. W Symfony wersją LTS jest zawsze ostatnie wydanie gałęzi, czyli X.4, np. 6.4 lub 7.4.
Jak często wychodzą nowe wersje Symfony?
Nowa wersja pośrednia ukazuje się co sześć miesięcy, w maju i w listopadzie. Nowa wersja główna pojawia się co dwa lata, w listopadzie, razem z wersją LTS poprzedniej gałęzi. Wydania poprawkowe ukazują się regularnie pomiędzy nimi.
Kiedy wyjdzie Symfony 8.2?
Symfony 8.2 jest planowany na listopad 2026. Będzie wersją standardową, wymagającą PHP 8.4, ze wsparciem do lipca 2027.
Kiedy będzie następna wersja LTS?
Zgodnie z kalendarzem następną wersją LTS będzie Symfony 8.4, w listopadzie 2027. W tym samym czasie ukaże się Symfony 9.0.
Jak długo jest wspierany Symfony 7.4?
Symfony 7.4 LTS otrzymuje poprawki błędów do listopada 2028, a poprawki bezpieczeństwa do listopada 2029.
Czy aktualizacja wersji pośredniej może zepsuć aplikację?
W obrębie jednej wersji głównej Symfony gwarantuje kompatybilność wsteczną publicznego API, więc aktualizacja, np. z 7.3 do 7.4, nie powinna wymagać zmian w kodzie. Wyjątkiem jest kod oznaczony jako wewnętrzny lub eksperymentalny.
Podsumowanie
Cykl wydań Symfony jest przewidywalny: wersja pośrednia co pół roku, wersja główna co dwa lata, a co dwa lata nowa wersja LTS z czteroletnim wsparciem bezpieczeństwa. Na dziś najważniejsze są trzy daty: Symfony 8.2 w listopadzie 2026, koniec poprawek błędów w Symfony 6.4 w tym samym miesiącu oraz Symfony 8.4 LTS w listopadzie 2027.
Więcej o frameworku znajdziesz w przewodniku Symfony: kompletny przewodnik po frameworku PHP.