-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Upgrade from 3.3 to 3.4 & 4.0 #673
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
Conversation
Even though it doesn't a blocker to migrate to 4.0, look weird auto-registration for classes that already are excluded by configuration |
The SwiftmailerBundle deprecations have been reported in symfony/swiftmailer-bundle#191. |
The WhiteOctoberPagerfantaBundle deprecation is being fixed in sampart/WhiteOctoberPagerfantaBundle#173 |
The strange deprecation related to |
composer.json
Outdated
"symfony/yaml": "^3.3", | ||
"twig/extensions": "^1.5", | ||
"doctrine/doctrine-fixtures-bundle": "2.4.0", | ||
"erusev/parsedown": "1.6.3", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why exact requirements everywhere ? This is clearly no a best practice (forbidding to update patch releases with a simple composer update
makes maintenance harder)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NVM, it's a temporal change to avoid updating these dependencies right now, later these constraints will be reverted, just say: stop! don't move!! :) because "minimum-stability": "dev"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But 3/4 of the dependencies are not in the composer.json (as they are transitive deps), and these are still updated to dev versions. So I don't think these changes make sense (and they make the review harder, as well as the future maintenance)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these are still updated to dev versions.
That's why I added "symfony/lts": "dev-master"
to avoid transitive deps updating to 4-dev, all of them are forced to 3-dev state ATM.
So I don't think these changes make sense (and they make the review harder, as well as the future maintenance)
I guess you're refering to changes like this "erusev/parsedown": "1.6.3"
? if so, they are temporal changes to avoid updating these deps right now. The "minimum-stability": "dev"
option forces all deps to dev unless there is a constraint that prevents it (that's I did with Symfony transitive deps symfony/lts
).
We need these changes to rely on Symfony 3/4-dev deps only. I think isn't a good idea rely on all dev deps during the migration to 4.0, since we would be testing against dev deps that later they might not work or simply don't work on master.
When the upgrade process finishes, we can go back safely to normal constraints 1.6.3
> ^1.6
, remove "minimum-stability": "dev"
option, remove symfony/lts
and fix the Symfony deps ^4.0@dev
> ^4.0
.
If it isn't reasonable, please, what would be the alternative during this upgrade?
In this PR we can also move |
Makefile was removed from Flex (see symfony/flex#184) so we need to remove it here too. Thanks! |
@javiereguiluz done! also the session deprecations are gone after update vendors. |
src/Command/AddUserCommand.php
Outdated
@@ -44,6 +44,10 @@ | |||
*/ | |||
class AddUserCommand extends Command | |||
{ | |||
// to make your command lazily loaded, either define its $defaultName static property, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
either
does not make sense if you don't have a or
later
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, thanks!
src/Command/AddUserCommand.php
Outdated
@@ -68,8 +72,7 @@ public function __construct(EntityManagerInterface $em, UserPasswordEncoderInter | |||
protected function configure() | |||
{ | |||
$this | |||
// a good practice is to use the 'app:' prefix to group all your custom application commands | |||
->setName('app:add-user') | |||
// you don't need to call ->setName() for configuring the command when it is lazy. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this comment is useless (people won't see setName at all)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
removed.
src/Command/AddUserCommand.php
Outdated
@@ -44,6 +44,10 @@ | |||
*/ | |||
class AddUserCommand extends Command | |||
{ | |||
// to make your command lazily loaded, configures the $defaultName static property, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo: configures the $defaultName...
-> configure the $defaultName...
Suggestion: only when the app:add-user command is actually called
-> only when the command is actually called
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Javier, done.
|
|
|
Doctrine warnings are gone after update to |
@yceruto I'm testing the latest changes of this PR. Your work is great. Thank you! I only have a question: when running tests I just see 1 deprecation, but when running the application in the browser I see many more. Do you know why? |
@javiereguiluz I think some of them are coming from the DebugClassLoader, and so depend on whether the class is loaded or no. |
and the profiler also redisplays the deprecations from the compile-time, even though the cached container was used. The PHPUnit Bridge does not. It only reports deprecations actually happening during the tests. |
Do you consider this behavior something to be improved? I'd like to run tests and get ALL deprecations, instead of having to browse the application manually. Thanks! |
@javiereguiluz reporting compile-time deprecations in the bridge would be quite hard. There is nothing triggering a |
@dmaicher we might need a new release to avoid use |
We can't move forward until |
@yceruto I created a new release that allows Symfony 4 |
I've tested the latest changes and I still see these four deprecations. How can we solve them? Thanks!
|
In my local fork I've removed all deprecations as follows:
|
@javiereguiluz perhaps we can ignore 2 & 3, as they'll disappear in 4.0 |
I don't know why, but after update deps |
About
You should set the It's done directly in the Kernel in the fwb recipe |
@ogizanagi yeah, I know :) but the parameter is useless in 4.0 and this PR ends there. Same for the another one, setting The only blocker to move to 4.0 is #673 (comment) right now :/ |
sampart/WhiteOctoberPagerfantaBundle#173 merged! We are already in Symfony 4.0! Just waiting for a new release of |
Tests are green now, this PR is ready? or should we wait for the stable release? |
@yceruto to make your life easier, I think we should merge this as is ... and keep updating to other betas, RCs and the stable version in separate PRs. That would also help others test these changes more easily. If nobody disagrees with this idea, I'll merge it tomorrow morning. Thanks! |
@javiereguiluz totally agree! |
Merged! We're in Symfony 4!!! Thanks @yceruto! |
# when the service definition only contains arguments, you can omit the | ||
# 'arguments' key and define the arguments just below the service class | ||
App\Twig\AppExtension: | ||
$locales: '%app_locales%' | ||
|
||
App\EventSubscriber\CommentNotificationSubscriber: | ||
$sender: '%app.notifications.email_sender%' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe rename property and remove this definition too?
Remaining deprecation notices:
SwiftmailerBundle
User Deprecated: The "swiftmailer.mailer.default.plugin.messagelogger" service is private, checking for its existence is deprecated since Symfony 3.2 and will fail in 4.0.User Deprecated: The "swiftmailer.mailer.default.plugin.messagelogger" service is private, getting it from the container is deprecated since Symfony 3.2 and will fail in 4.0. You should either make the service public, or stop using the container directly and use dependency injection instead.User Deprecated: The "mailer" service is private, checking for its existence is deprecated since Symfony 3.2 and will fail in 4.0.The "swiftmailer.mailer.default.transport.real" service is private, getting it from the container is deprecated since Symfony 3.2 and will fail in 4.0. You should either make the service public, or stop using the container directly and use dependency injection instead.WhiteOctoberPagerfantaBundle
User Deprecated: The "white_october_pagerfanta.view_factory" service is private, getting it from the container is deprecated since Symfony 3.2 and will fail in 4.0. You should either make the service public, or stop using the container directly and use dependency injection instead.Symfony
The Symfony\Component\HttpFoundation\Session\Storage\Handler\NativeSessionHandler class is deprecated since version 3.4 and will be removed in 4.0. Use the \SessionHandler class instead.User Deprecated: The Symfony\Component\HttpFoundation\Session\Storage\Proxy\SessionHandlerProxy class is deprecated since version 3.4 and will be removed in 4.0. Use your session handler implementation directly.User Deprecated: The Symfony\Component\HttpFoundation\Session\Storage\Proxy\AbstractProxy class is deprecated since version 3.4 and will be removed in 4.0. Use your session handler implementation directly.User Deprecated: The "Doctrine\DBAL\Configuration" class is considered internal When adding a new configuration option just write a getter/setter pair and add the option to the _attributes array with a proper default value. It may change without further notice. You should not use it from "Doctrine\ORM\Configuration".Setting logout_on_user_change to false is deprecated as of 3.4 and will always be true in 4.0. Set logout_on_user_change to true in your firewall configuration. (isn't a blocker for 4.0)Relying on service auto-registration for type "App\Entity\Post" is deprecated since version 3.4 and won't be supported in 4.0. Create a service named "App\Entity\Post" instead. (isn't a blocker for 4.0)User Deprecated: The "Symfony\Bridge\Doctrine\ManagerRegistry::setContainer()" method is deprecated since version 3.4 and will be removed in 4.0. Inject a PSR-11 container using the constructor instead.