2021 habe ich ein Kundenprojekt auf die fluent Config-Builder umgestellt, die mit Symfony 5.3 kamen. Methodenketten, Autocompletion, das ganze SecurityConfig-Erlebnis. Es fühlte sich an wie die erwachsene Art, ein Framework zu konfigurieren. Vier Jahre später ist dieses Format in 7.4 deprecated und aus dem empfohlenen Pfad verschwunden, und meine erste Reaktion war ein langes Ausatmen am Schreibtisch. Meine zweite Reaktion, nachdem ich die Begründung tatsächlich gelesen hatte: Symfony macht hier das Richtige, und diese Position will ich verteidigen, obwohl sie mich einen Nachmittag Migrationsarbeit gekostet hat.

Erst die Fakten. Symfony 8.0 erschien am 27. November 2025, Seite an Seite mit dem 7.4 LTS. Gleiche Codebasis, minus alles, was 7.4 deprecated hat. Dazu gehört der XmlFileLoader für Service-Definitionen und Routen, deprecated per PR #60568 von Mathieu Lechat im Oktober 2025 und jetzt schlicht nicht mehr da. Wenn deine App, oder irgendein Bundle in deinem vendor-Verzeichnis, noch darauf angewiesen ist, dass eine services.xml oder routes.xml geladen wird, bootet sie unter 8.0 nicht. YAML dagegen ist ausdrücklich sicher: Das Core-Team hat erklärt, eine Deprecation sei nicht geplant, und die Recipes generieren es weiterhin standardmäßig.

Und hier das Argument, das ich machen will: Zwanzig Jahre lang haben wir das Config-Format als Geschmacksfrage behandelt, und dieser Rahmen war immer leicht schief. Die eigentliche Frage ist, was deine Tools verifizieren können, bevor der Container kompiliert. XML hatte ein Schema, klar, aber das Ökosystem hat nie modernen Editor-Support darum herum gebaut, und Flex hat es nie geschrieben. Die fluent Builder wirkten entwicklerfreundlich, aber Nicolas Grekas hat den fatalen Fehler erklärt: Sie zwingen jeden Config-Tree in eine einzige kanonische Form, was automatische Recipe-Updates unmöglich macht. Ein Format, das gegen deinen Paketmanager kämpft, verliert, egal wie schön es sich liest.

Was beides ersetzt, ist aufschlussreich. Das neue PHP-Format besteht aus schlichten Arrays, verpackt in App::config() oder Routes::config(), und der Trick ist, dass Symfony Array-Shape-Metadaten in eine Datei config/reference.php generiert, die PHPStan, Psalm und PhpStorm konsumieren können. Deine Config wird zu etwas, das ein statischer Analyzer auf falsche Keys prüfen kann, bevor du je cache:clear auf Staging ausführst. YAML bekam dieselbe Behandlung aus einer anderen Richtung: 7.4 bringt JSON-Schemas für Services-, Routen-, Validation- und Serializer-Dateien, referenziert über einen yaml-language-server-Kommentar, den Editoren aufgreifen. Zwei Formate, beide maschinell prüfbar. Das ist Konvergenz, kein Hin und Her.

Jetzt das ehrliche Zugeständnis, denn es gibt ein echtes. XML war jahrelang das offiziell empfohlene Format für Bundle-Autoren, und etliche halbwegs gepflegte Pakete liefern ihre interne Verdrahtung immer noch als Resources/config/services.xml aus. Diese Bundles degradieren unter 8.0 nicht sanft, sie funktionieren schlicht gar nicht mehr. Und die fluent Builder haben von der Einführung bis zur Deprecation vier Jahre gehalten, genau die Art Lebensdauer, die Teams zögern lässt, bevor sie irgendetwas Neues aus dem Framework übernehmen. Die reference.php hat ebenfalls ihre rauen Kanten: Sie ändert sich bei jedem Dependency-Wechsel, also wachsen deinen Pull Requests verrauschte Diffs, und mindestens ein Nutzer stieß auf kaputte Generierung wegen eines Globs wie **/*.graphql in einem Config-Wert. Nichts davon ist gratis.

Ich lande trotzdem da, wo ich lande, aus zwei Gründen. Erstens wird niemand von der Klippe geschubst. 7.4 LTS bringt vier Jahre Security-Support, fährt alte und neue Formate parallel und gibt dir ein Deprecation-Log, das du tatsächlich abarbeiten kannst. Es gibt einen Community-Konverter unter github.com/GromNaN/symfony-config-xml-to-php, der Bundle-XML ins Array-Format umschreibt, und dessen Output als PR upstream zu schicken ist eine wirklich sinnvolle Art, eine Stunde zu investieren. Zweitens ist Symfony ungewöhnlich offen, was die eigene Timeline angeht: Der Blog sagt klipp und klar, dass das Array-Format noch nicht der empfohlene Standard ist, weil der Editor-Support für komplexe Array-Shapes uneinheitlich ist und Flex bislang nur YAML spricht. Ein Framework, das sagt „das ist die Richtung, aber spring noch nicht", hat sich nach der Fluent-Builder-Episode ein Stück Vertrauen zurückverdient, zumindest bei mir.

Mein praktischer Rat weicht also in beide Richtungen vom Format-Enthusiasmus ab. Lass dein funktionierendes YAML in Ruhe, ergänze die Schema-Kommentare, genieß die Autocompletion. Schreib wirklich neue Config im Array-Format, wenn dein Team ohnehin PHPStan fährt, denn da liegt der Hebel. Und bevor du überhaupt für 8.0 branchst, grep dein vendor-Verzeichnis nach XML-Config, denn das Bundle, das du 2019 vergessen hast, ist das, was dich am Ende wirklich blockiert. Bleibt die Frage, die ich immer wieder hin und her wälze: Wenn das Array-Format reift und Flex lernt, es zu schreiben, wird YAML-Config dann in fünf Jahren still zu Legacy, oder ist ein menschenlesbares Format mit Schema-Validierung schlicht der bessere Endzustand für Application-Config? Ich bin diese Woche zweimal umgeschwenkt. Sag mir, wo du landest.