In 2021 I converted a client project to the fluent config builders that arrived with Symfony 5.3. Method chains, autocompletion, the whole SecurityConfig experience. It felt like the grown-up way to configure a framework. Four years later that format is deprecated in 7.4 and gone from the recommended path, and my first reaction was a long exhale at my desk. My second reaction, after actually reading the reasoning, was that Symfony is doing the right thing, and I want to defend that position even though it cost me an afternoon of migration work.

The facts first. Symfony 8.0 shipped on November 27, 2025, side by side with the 7.4 LTS. Same codebase, minus everything 7.4 deprecated. That includes the XmlFileLoader for both service definitions and routes, deprecated via PR #60568 by Mathieu Lechat in October 2025 and now simply absent. If your app, or any bundle in your vendor directory, still relies on a services.xml or routes.xml being loaded, it will not boot on 8.0. YAML, meanwhile, is explicitly safe: the core team has said its deprecation is not planned, and recipes keep generating it by default.

Here is the argument I want to make: for twenty years we treated config format as a matter of taste, and that framing was always slightly wrong. The real question is what your tools can verify before the container compiles. XML had a schema, sure, but the ecosystem never built modern editor support around it, and Flex never wrote it. The fluent builders looked developer-friendly, but Nicolas Grekas explained the fatal flaw: they lock each config tree into one canonical shape, which makes automatic recipe updates impossible. A format that fights your package manager loses, no matter how nice it reads.

What replaces both is instructive. The new PHP format is plain arrays wrapped in App::config() or Routes::config(), and the trick is that Symfony generates array shape metadata into a config/reference.php file that PHPStan, Psalm and PhpStorm can consume. Your config becomes something a static analyzer can check for wrong keys before you ever hit cache:clear in staging. YAML got the same treatment from a different angle: 7.4 adds JSON schemas for services, routes, validation and serializer files, referenced through a yaml-language-server comment that editors pick up. Two formats, both machine-checkable. That is convergence, not churn.

Now the honest concession, because there is a real one. XML was the officially recommended format for bundle authors for years, and plenty of maintained-ish packages still ship their internal wiring as Resources/config/services.xml. Those bundles do not degrade gracefully on 8.0, they stop working entirely. And the fluent builders lasted four years from introduction to deprecation, which is exactly the kind of lifespan that makes teams hesitate before adopting anything new from the framework. The reference.php file has its own rough edges too: it churns on every dependency change, so your pull requests grow noisy diffs, and at least one user hit broken generation from a glob like **/*.graphql in a config value. None of this is free.

I still land where I land, for two reasons. First, nobody is being pushed off a cliff. 7.4 LTS carries four years of security support, runs old and new formats side by side, and gives you a deprecation log you can actually work through. There is a community converter at github.com/GromNaN/symfony-config-xml-to-php that rewrites bundle XML into the array format, and sending its output upstream as a PR is a genuinely useful way to spend an hour. Second, Symfony is being unusually candid about its own timeline: the blog states outright that the array format is not the recommended default yet, because editor support for complex array shapes is uneven and Flex still only speaks YAML. A framework that says "this is the direction, but don't jump yet" has earned some trust back from the fluent-builder episode, at least in my book.

So my practical advice diverges from format enthusiasm in both directions. Leave your working YAML alone, add the schema comments, enjoy the autocompletion. Write genuinely new config in the array format if your team runs PHPStan anyway, because that is where the leverage is. And before you even branch for 8.0, grep your vendor directory for XML config, because the bundle you forgot about in 2019 is the thing that will actually block you. Which leaves me with the question I keep turning over: when the array format matures and Flex learns to write it, does YAML config quietly become legacy in five years, or is a human-readable format with schema validation simply the better end state for application config? I have flip-flopped twice this week. Tell me where you land.