maybe it can be generated from the Configuration definition?

What do you mean by "it"?

deprecating format X can be really painful for (some) users, im not sure it's generally worth it, since it's just format X

I agree but I really didn't see any project using it. More over, this configuration formation is painful to use (event for end user)

And Doctrine has already removed a configuration format. So there is a precedent 😃

maybe it can be generated from the Configuration definition?

This is not trivial as there is some transformations of the input before validating the configuration (example in DoctrineBundle) that requires a specific schema file. We hit this issue while trying to generate the JSON schema configuration in #59620

And I never saw a project using XML to configure the framework.

We can decide to deprecate this format and possibly reconsider this decision before deleting it, if people contest with specific use cases. Let's try to gather feedback before committing the deprecation.

maybe do some public polls first?

I'd like to, but I don't know where we could put it to reach the maximum number of people.

I'd like to, but I don't know where we could put it to reach the maximum number of people.

During https://live.symfony.com/

I think there is 2 different cases here:

• XML support for the semantic configuration of bundles (which can be quite complex to handle as it is dynamic, and most non-core bundles don't care about providing an XSD)
• XML support for Symfony configuration files (service definitions, routes, etc...), for which the XSD is quite straightforward

I know that some projects use XML files for the second case (the XSD provides better IDE support that for Yaml files for instance).
I'm not sure it is worth deprecating those.

Reading the issue again, I see that it proposes only the deprecation of the first case. I got confused by #60568 that deprecates everything about XML when claiming to fix this issue.

I'm in favor of dropping everything XML-related. Json-schema & array-shapes to the rescue instead of XSD if we want to provide an alternative IMHO.

Using XML for services and routes definition has been the dominant practice in popular bundles.

• Sulu: https://github.com/sulu/sulu/blob/2.6/src/Sulu/Bundle/MarkupBundle/Resources/config/services.xml
• API Platform: https://github.com/api-platform/core/tree/4.1/src/Symfony/Bundle/Resources/config

Let's focus on semantic configuration first, which is much more rarely (if ever) used.

Sure, that's why we need to deprecate first, then remove as usual. Keeping part of the xml stuff wouldn't allow us to remove any code, making the effort worthless. On the contrary, sending a message to bundles that they should move to php config is desirable - the format exists long enough.

Let's focus on semantic configuration first, which is much more rarely (if ever) used.

I would start with this first 👍🏼

Keeping part of the xml stuff wouldn't allow us to remove any code

No, we well be able to drop some code!

• In the Configuration class
  • there are lots of workarround to support XML
  • fixXmlConfig()
• My nemesis : https://github.com/symfony/symfony/blob/7.4/src/Symfony/Bundle/FrameworkBundle/Resources/config/schema/symfony-1.0.xsd (well, actually I'm not okay with XSD 🤓)
• many fixtures, tests, etc

Not sure what y'all mean by "first": maintaining XML loaders for 5 more years in 8.x cycle? Better not!

héhé, just to clarify : I don't like to maintain XML support in semantic configuration. I don't really maintain routing & service configuration. That's why I wanted to remove only semantic configuration.

But if we all agree to drop all XML configuration, I'm obviously okay with that!