Fourteen YAML files in config/packages, and every one of them opens with the same word. I counted them on a Thursday night when a staging mailer refused to send. Before I could even look at the DSN I had to scroll through framework:, then mailer:, then the actual value, in a file already called mailer.yaml. Symfony 8.2 makes that first line optional. My argument is that you should treat optional as a polite way of saying it's on its way out. When you bump to 8.2, delete the prefix in that same pull request. Don't wait for a deprecation notice to make you do it.

# old form, still accepted in Symfony 8.2 via aliases
framework:
  mailer:
    dsn: '%env(MAILER_DSN)%'

# new form, owned by MailerBundle
mailer:
  dsn: '%env(MAILER_DSN)%'

The facts are short. In 8.2, 29 components that used to be configured inside FrameworkBundle now ship their own bundle, and it registers itself as soon as the component is installed, so config/bundles.php stays untouched. Each bundle derives its root key from its class name: MailerBundle answers to mailer, PropertyInfoBundle to property_info. FrameworkBundle keeps the parts that really belong to the HTTP layer, such as sessions, CSRF, the profiler and fragments. For maintainers this is the headline: a new Mailer option is now a change to symfony/mailer and nothing else. For those of us who only write config, the visible change is the vocabulary.

And the vocabulary is where I think the release is quietly asking something of us. The old keys keep working because FrameworkBundle declares them with a new NodeDefinition::aliasOf() and forwards them to the component's extension before anything loads. That's elegant. But the tooling has already switched to the new names. If you want to see your effective HTTP client settings, you now run debug:config http_client. The framework path is gone from that command. Three roots also changed spelling on the way: assets became asset, translator became translation, workflows became workflow. A codebase that still writes the old form is now saying one thing in its files while the console says another.

Here is the best case against me, and it's a good one. The Symfony team chose aliases over deprecation specifically so nobody would have to touch working config. A diff that removes an indentation level from every package file ships nothing to a single user. It conflicts with every open branch that touches config, and it gives a reviewer forty lines of whitespace noise to approve on faith. If your team runs a handful of apps and upgrades on a schedule, leaving framework: alone is a defensible use of your afternoon. I've made that call myself on less important things.

I still come down on the other side, because the one real behavior change in this release shows why honest structure matters. Under the old single extension, switching on Forms also switched on Validation, simply because of where the code that registered them happened to sit. In 8.2 each component decides for itself, and Validation shows up because symfony/validator is installed, not because Forms invited it. Most apps that use forms have the validator anyway, so nothing breaks. The lesson is about legibility, though. The framework took away a coupling you could only find by reading the code. Your config should stop pretending that coupling still exists.

There's a practical reason too, and it's about timing. The upgrade PR is the one moment everyone expects config/packages to change. Reviewers are already looking there, CI is already running the whole suite, and git blame will point the rename at a commit called "Symfony 8.2", which explains itself in a year. Do it six months later as a standalone tidy-up and it's a mystery diff from someone who apparently had a slow week. Do it never, and the next hire learns two spellings for the same setting from your repo. Either way you end up paying, and paying later costs more.

I'll admit the split excites me more on the worker side than on the web side. A Messenger consumer has no use for sessions or a profiler, and now it doesn't have to carry them. You register ConsoleBundle and the component bundles the worker actually touches. Bundles with no runtime work also stay as plain class names until something asks for them, and MimeBundle is the deliberate exception because its default MIME types have to be set on every request. My Go-writing friends like to bring up how small their binaries are. A Symfony worker that boots only what it uses is a fair answer to that, and no less PHP for it.

So my rule is that the upgrade and the rename ship together, with one commit for each so the reviewer can skim the second. I know this is a judgement call, and some of you run fleets of apps where config churn is a real cost. If you're keeping framework: on purpose, I'd like to know what would change your mind. Would it take an actual deprecation in a later release, or is there a reason the aliases should live forever that I'm not seeing?