Diese Frage taucht in fast jedem Projekt auf: Setzen wir auf ein Symfony LTS-Release oder auf die aktuelle Standard-Version? Meist wird sie in fünf Minuten entschieden — und dann drei Jahre lang bereut. Denn hinter der scheinbar simplen Versionswahl steckt eine Entscheidung darüber, wie oft Ihr Team updaten will, wie viel Risiko es tragen kann und wie Ihr Deployment aufgestellt ist.
Ich erlebe das regelmäßig bei Legacy-Anwendungen: Der Code läuft seit Jahren stabil, die Fachlogik ist erprobt — aber die Symfony-Version ist auf einem Stand, den niemand mehr pflegen kann. Und häufig war der ursprüngliche Fehler nicht die alte Version, sondern eine falsch verstandene Erwartung an das, was "LTS" eigentlich bedeutet.
Wie das Symfony-Release-Modell wirklich funktioniert
Symfony bringt jährlich mehrere Minor-Releases heraus (z. B. 6.1, 6.2, 6.3, 6.4). Jedes Standard-Minor-Release wird typischerweise acht Monate mit Bugfixes und zwei weitere Monate mit Sicherheitsfixes versorgt — danach ist Schluss. Das letzte Minor-Release eines Major-Zyklus (also .4, etwa 5.4 oder 6.4) ist das Symfony LTS-Release. Es erhält drei Jahre Bugfixes und vier Jahre Sicherheitsfixes.
Wichtig ist ein Detail, das oft untergeht: Die LTS-Version enthält funktional exakt dasselbe wie das gleichzeitig erscheinende neue Major-Release. Symfony 5.4 und 6.0 wurden am selben Tag veröffentlicht und waren feature-identisch. Der einzige Unterschied: 6.0 hat die veralteten APIs (Deprecations) entfernt, 5.4 behält sie noch. LTS ist also kein "abgespeckter, stabilerer Sonderzweig" — es ist der reguläre Code plus verlängerte Wartung und Rückwärtskompatibilität.
Was für das Symfony LTS-Release spricht
Der ehrliche Grund für LTS ist selten "Stabilität" im technischen Sinne — die Standard-Releases sind genauso stabil. Der eigentliche Vorteil ist Update-Frequenz:
- Seltenere Zwangs-Upgrades: Mit einem Standard-Release müssen Sie etwa alle acht Monate auf das nächste Minor gehen, um im Support zu bleiben. Ein LTS gibt Ihnen mehrere Jahre Luft.
- Planbarkeit für Teams mit wenig Kapazität: Wenn niemand regelmäßig Zeit für Framework-Wartung hat, ist ein langer Support-Horizont Gold wert.
- Stabile Basis für Bibliotheken: Viele Bundles und Pakete testen primär gegen LTS-Versionen. Die Kompatibilität ist in der Regel breiter abgesichert.
- Berechenbare Dependencies: In regulierten Umgebungen oder bei langen Freigabeprozessen ist der 4-Jahres-Security-Horizont ein handfestes Argument.
Was für das aktuelle Standard-Release spricht
Die Kehrseite: Wer auf LTS "parkt", verpasst Features und sammelt technische Schulden an, die sich beim nächsten Major-Sprung bündeln. Für das Standard-Release spricht:
- Neue Features sofort: Verbesserungen an Serializer, Messenger, Security oder AssetMapper stehen Ihnen direkt zur Verfügung, statt Jahre später.
- Kleine, kontinuierliche Upgrades statt großer Sprünge: Von 6.3 auf 6.4 zu gehen ist trivial. Von 5.4 auf 6.4 in einem Rutsch dagegen ist ein Projekt. Wer regelmäßig aktualisiert, hält die Deltas klein.
- Deprecations laufend abbauen: Symfony meldet veraltete APIs zur Laufzeit. Wer diese Warnungen fortlaufend abarbeitet, macht den Major-Upgrade fast zum Nicht-Ereignis.
Der Punkt, den ich betonen möchte: Ein Standard-Release ist nur dann die riskantere Wahl, wenn Sie nicht updaten. Wer den Rhythmus mitgeht, hat am Ende weniger Schmerzen als jemand, der drei Jahre auf LTS sitzt und dann einen Major-Sprung mit hundert gebündelten Änderungen vor sich hat.
Die ehrliche Entscheidungsfrage
Die Versionswahl ist in Wahrheit eine Frage an Ihr eigenes Verhalten. Stellen Sie sich diese drei Fragen ehrlich:
- Haben Sie einen festen Wartungs-Slot? Wenn Framework-Updates fest eingeplant sind (etwa vierteljährlich) und automatisiert getestet werden, spricht viel für das Standard-Release. Wenn "wir machen das, wenn Zeit ist" die Realität ist, wählen Sie LTS — sonst landen Sie auf einer toten Version.
- Wie gut ist Ihre Testabdeckung? Ohne aussagekräftige Tests ist jedes Upgrade ein Blindflug. Dann ist der längere LTS-Horizont ein Sicherheitsnetz — aber eigentlich ist die fehlende Testabdeckung Ihr wahres Problem, nicht die Symfony-Version.
- Wie sieht Ihr Deployment aus? Können Sie in Minuten deployen und zurückrollen? Dann sind häufige kleine Updates kein Risiko. Ist jedes Deployment ein manueller Kraftakt, meiden Sie Frequenz — und damit eher das Standard-Release.
Der häufigste Fehler: LTS als Ausrede
In der Praxis sehe ich einen wiederkehrenden Fehlschluss. Teams wählen LTS "für die Stabilität", updaten dann aber innerhalb des LTS-Zweigs auch nicht die Patch-Releases und bleiben Jahre auf demselben Minor. Das Ergebnis: eine Anwendung auf einer LTS-Version, die formal noch Sicherheitsfixes bekäme — nur werden die nie eingespielt. Das ist kein LTS-Problem, das ist ein Prozess-Problem.
Genau hier zeigt sich mein Grundsatz aus der Legacy-Arbeit: Eine Anwendung, die seit Jahren zuverlässig läuft, ist kein Sanierungsfall — sie ist der Beweis, dass die Fachlogik trägt. Das Problem sitzt fast nie in der Domäne, sondern in der Peripherie: veraltete Abhängigkeiten, fehlende Tests, ein Deployment, das niemand anzufassen wagt. Eine komplette Neuentwicklung, um "endlich auf die aktuelle Symfony-Version zu kommen", ist in aller Regel die teuerste und riskanteste Option. Der pragmatische Weg ist fast immer, die bestehende App schrittweise upgradefähig zu machen — Deprecations abbauen, Tests nachrüsten, dann Version für Version nachziehen.
Eine praktische Faustregel
Wenn Sie ein aktiv weiterentwickeltes Produkt mit einem Team haben, das regelmäßig Zeit für Wartung einplant und automatisiert testet: Bleiben Sie nah am aktuellen Standard-Release und gehen Sie die Minor-Upgrades kontinuierlich mit. Wenn die Anwendung stabil ist, selten angefasst wird und die Wartungskapazität knapp ist: Wählen Sie das Symfony LTS-Release — aber verpflichten Sie sich, wenigstens die Patch-Releases zeitnah einzuspielen. Beide Wege funktionieren. Der einzige, der garantiert schiefgeht, ist "wir entscheiden uns für eine Version und schauen sie danach nie wieder an".
Praxis-Tipp zum Schluss: Aktivieren Sie das Symfony-Deprecation-Logging in Ihrer Test-Suite und lassen Sie den Build bei neuen Deprecations zumindest eine Warnung ausgeben. So sehen Sie den Aufwand für den nächsten Major-Sprung jederzeit — statt ihn erst am Umstellungstag zu entdecken. Wenn genau dieser Schritt bei einer festgefahrenen Legacy-Anwendung ansteht, unterstützt LegacyWerk dabei, sie wieder upgradefähig zu machen, ohne alles neu zu bauen.
