Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[RFC] [Kernel] Add the Kernel component #29275
Be able to provide a very tiny application with the power of the DIC.
Add ability to use the Dependency Injection factory without HTTP dependencies.
One solution is to create the
For history: a similar work has been done for the
Symfony took the path to be tiny and fast. However, CLI applications still required the
There are also other projects that wants to use or initiate the migration to Symfony. Where migrating the business logic to use the dependency injection component is one of the first action to do.
What will this component contain?
All not HTTP related features of the
Next (out of topic)
Migration path (draft)
To migrate to Symfony5: rename the namespace for classes moved to the new component.
-namespace Symfony\Component\HttpKernel\*; +namespace Symfony\Component\Kernel\*;
referenced this issue
Nov 21, 2018
your migration path is incomplete. What is the migration path for bundles needing to support multiple versions of Symfony (and without getting a deprecation warning, so that they don't get bug reports from all their user requiring them to migrate in a way dropping support for the old version) ?
Did you mean "Add ability to use the Dependency Injection outside of HTTP context." (without the factory)?
BTW i like this RFC very much, thanks @alquerci !
Do you mean for bundles that wants to support multiple major versions of Symfony. However, even for minor versions this is a good question. So the road to find a solution is to test it. Can you provide a bundle for which this case will happen.
Deprecation are caught and triggered by the debug component even for third party libraries? For this case that is not the first deprecation on the Symfony life. But this one have a different impact, is it?
This is for sure something to resolve before going forward.
Symfony already provides the ability to use the DIC without any factory. The main scope of this issue is about the DIC factory.
To use the
For the ecosystem, we need to allow supporting LTS + next major version at the same time (otherwise bundles will drop support for the LTS, making it useless) and also multiple minor versions at the same time.
It is indeed not the first one. But we also already rejected some changes in the past because the migration path for the ecosystem was considered too high compared to the benefit. And recently (in #29218), we reverted a deprecation, delaying it to the future, for a similar reason. Considering the cost of the migration, both for projects and for the open-source ecosystem is a necessary part of the decision about deprecating something.
Then if I correctly understood: On version 4.3 adding the component with the BC layer then the deprecation will be triggered on version 5.1 and the BC layer removed for version 6.0.
--- before 2018-11-22 20:55:35.352978864 +0100 +++ after 2018-11-22 20:55:40.337007783 +0100 @@ -5,3 +5,5 @@ * Provides a back compatibility layer for Symfony4. * The `symfony/http-kernel` requires and extends the new `symfony/kernel` component. - [ ] Extract, migrate, refactor the documentation +- [ ] Trigger deprecation on version 5.1 +- [ ] Remove BC layer on version 6.0
No, this means adding the component in 4.3 must not break anything, it can deprecate old behaviors, and the deprecated code will be removed/modified for 5.0.
With your roadmap, waiting for 6.0 to remove BC layer means that you would have to wait until 2021 for the feature to come... A bit too long, maybe :)
However, with a better migration path (like adding the component for 4.3 and make it not break anything), you might be able to mark the component as experimental if necessary, so the existing code would still work, but if the new component is required, it's used, and might introduce breaks in next minor (this is mostly valid if the component is released in 4.3, that wouldn't be the case for 4.4 because there is no next minor in this case).
To me, if the component is accepted by the core team, it needs to be released in 4.3 or 4.4, and old code must be removed in 5.0, in one year
I hope I don't miss anything about the release process
The feature is to extract the DIC factory from the HttpHernel. Then as soon as the new component is released the feature going live too.
What did you expect?
That's already the plan as you can see on Resources section.
Can you share what will be broken even with the BC layer?
I am ready to find a solution for each blocker points.