I'm very glad to see this is being given more attention again 👍

The best would be to have Symfony Standard edition using this, so there will only be only one bundle registered at first in AppKernel : Symfony\StandardEditionBundle() dreaming ☁️

@Pierstoval I don't see any value in StandardEditionBundle. It would make things less clear, as you suddenly can't see what bundles are registered. You're not adding them to the kernel yourself as they're there when you initialize the project, so I really don't see an issue here. It would also complicate removal of bundles. For example, if I wanted to remove doctrine from a project I would need to replace StandardEditionBundle with all the bundles that it registers and then remove DoctrineBundle.

@jakzal You're right, but I'm thinking about beginners that don't yet know the concept of bundle. If the doc says that a bundle has to be registered in AppKernel, maybe he'll wonder what are the actually registered bundles. If he only sees Symfony\StandardEditionBundle , it's more verbose to him than Symfony\Bundle\MonologBundle\MonologBundle which is not verbose for beginners (monolog, even if it's terminated with "log", is not explicitly described as a logger bundle), added to the fact that beginners won't use the logger until they're familiar with either logging or debugging in Symfony.

Plus, the most important to me is to simplify the integration of a "Bundled bundle", as in #695 (in symfony-standard). The example of SonataPageBundle, which depends on more than 10 bundles ( ❗ ) would be simpler to register if you only have to add SonataPageBundle in your kernel.
In fact, when you install a new bundle, you want to use this bundle, and if it depends on other bundles (like SonataCacheBundle or SonataCoreBundle in our case) , you certainly won't mind how they work : you'll focus on the feature you want (a "page system" in our case).

For the case in which you'd want to remove DoctrineORM in your project, you're right. Probably the best solution for this is to use a powerful IDE that will allow you to Ctrl+Click on the class name to check all the bundle dependencies directly in the class, and then add them manually.
Anyway, the example of StandardEditionBundle might be a bit bad, and in fact, I wouldn't add "all" bundles to it, only some "almost mandatory" ones, like Security, Twig, FrameworkBundle, Monolog and SensioFrameworkExtraBundle. By the way, it can only come with a consensus, and it's not the principal topic ;)

+1. I think this is a great idea. If someone needs to disable a particular dependant bundle, then it can be controlled via config (eg. for the Doctrine case) or looking in the extension/configuration and copy & pasting.

If someone needs to disable a particular dependant bundle, then it can be controlled via config (eg. for the Doctrine case) or looking in the extension/configuration and copy & pasting.

@cjunge-work the config is about configuring registered bundles. Enabling bundles based on the config creates a circular loop (you need to register bundles before being able to provide config for them)

@stof maybe @cjunge-work was talking about something like the old #598 Put enabled bundles in a configuration file in symfony standard edition :)

@stof: I meant supporting a specific way to turning off bundles, in the config file. I know that the Bundle is instantiated, but the functionality can be disabled via config (eg. a lot of bundles don't work correctly until their config is enabled, sometimes as simple as bundle-name: ~).

Otherwise, the suggestion of @Pierstoval would suite.

Just throwing it out there... sure would help with those packages that require multiple bundles. As an example, I've started using SonataAdminBundle and SonataUserBundle in a project... the amount of back & forth over enabling bundles, setting config, etc is confusing!

Two PR's now exists for this issue, direction from core devs needed to help move this forward:

#13506
#13945

PS: None of them uses config files, so no request time overhead here besides additional function calls, which can be further optimized later (3.0)? for prod by introducing faster boot process, by means of caching both the existing parent/child and dependencies calculations, or even more..

@symfony/deciders I would like us to discuss this if we are going to put it into 2.7 .. obviously now we can also decide to delay it until 2.8 LTS but the decision should be conscious rather than accidental.

2.7 beta1 is out, so no new features can be added to it. It would be for 2.8.

Let's update #13945 in favor of the 2.8 branch then.
Ping @andrerom 😄

Ok, I will do that tomorrow :)