-
-
Notifications
You must be signed in to change notification settings - Fork 209
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PageExtension without deprecated InitRuntimeInterface #1436
PageExtension without deprecated InitRuntimeInterface #1436
Conversation
@Hanmac can you open to 3.x? we should remove the deprecation from 3.x and merge into 4.x |
well because this deprecations are in 3.x, and to upgrade from 3.x to 4.x, the guy need to solve all deprecations and after that he is safe to migrate to next major. for this reason we should solve the deprecations into the 3.x branch and after that merge into 4.x |
a78f5ef
to
4c1d74b
Compare
Could you please rebase your PR and fix merge conflicts? |
I disagree with @eerison, this should be done in 4.x. In 3.x, we only to add deprecation about what will be changed/removed in 4.x about the PageBundle. Here, not extending/implementing a class/interface is a BC-break. Sure there is almost no chance it will break someone code ; but we should stay with our BC-policy. The strategy for the user will be the following
|
hmmm I see, But in this case who uses Then what do you say, is we do not need to care about deprecations in |
4c1d74b
to
41a98a8
Compare
There is a comment that you need to solve 👀 |
It's not an issue. |
Thanks |
Subject
I am targeting this branch, because i don't know if that would count as BC.
Closes #{put_issue_number_here}.
it fixes:
The Thing about
$env->getGlobals()['app']->getRequest()->getPathInfo();
, my gut is telling me that RequestStack would be cleaner, but that wouldn't be BC anymore if this one might be.Changelog