doctrine / DoctrineFixturesBundle

Symfony integration for the doctrine/data-fixtures library
MIT License
2.44k stars 202 forks source link

add "void" as a native return type declaration #381

Closed PhilETaylor closed 1 year ago

PhilETaylor commented 1 year ago

!! 2023-04-08T19:35:15+00:00 [info] User Deprecated: Method "Symfony\Component\HttpKernel\Bundle\Bundle::build()" might add "void" as a native return type declaration in the future. Do the same in child class "Doctrine\Bundle\FixturesBundle\DoctrineFixturesBundle" now to avoid errors or add an explicit @return annotation to suppress this message.

greg0ire commented 1 year ago

Can you please a look at the conversation at https://github.com/doctrine/DoctrineMigrationsBundle/pull/492?

PhilETaylor commented 1 year ago

So surely the simple solution is just to bump the version number and add new code to the new major version? I can't do that only your project can. I'm not seeing what the difficulty is here?

derrabus commented 1 year ago

The difficulty is that we don't plan a new major at the moment.

PhilETaylor commented 1 year ago

The difficulty is that we don't plan a new major at the moment.

No worries, This is interpreted as "this project has no future". Got it.

greg0ire commented 1 year ago

Well we can create a branch for sure, no biggie. Still, creating a major release just for this would be a bit overkill. Why don't you apply the alternate solution mentioned in the deprecation message? Then we can merge, after you provide a convincing apology for your behavior of course.

PhilETaylor commented 1 year ago

after you provide a convincing apology for your behavior of course.

And that ends my contributions here and earns you a place on my block list.

Im sorry you feel that way. Its your project do as you want. I was only trying to be helpful. No one was demanding anything.

The fact is, the upstream project has chosen to add the return type, and now this project outputs warnings and you are choosing to ignore that rather than fix that. Your choice I guess.

greg0ire commented 1 year ago

Again, there is another way to fix it, if you would care to read the deprecation message, but slowly. I'd do it myself but I'm AFK.

PhilETaylor commented 1 year ago

"Suppressing" messages rather than fixing the root issue is not the way to avoid errors in the long term.

Continued personal insults is also a quick way to lose contributors. You don't deserve my contribution following your aggressive tone, demanding of an apology for simply contributing and now telling me to read "slowly"... Seems to happen often with Doctrine* projects.

Seems I was only using this Bundle for a small thing anyway, so I have refactored that into a Symfony command and removed this dependancy from my projects. Simple. Now the warning is gone and you don't need to talk to me again.

greg0ire commented 1 year ago

"Suppressing" messages rather than fixing the root issue is not the way to avoid errors in the long term.

We usually do both, that's how good we are. I don't want your contribution, I don't experience the issue.

derrabus commented 1 year ago

To anyone who wants to pick up the work: We are aware that we need to create a new major release for Symfony 7 eventually. For Symfony 6, this deprecation can be resolved without breaking changes. Symfony lets us do that by adding a PHPDoc block. This is the way to go here.

nicolas-grekas commented 1 year ago

Also: we won't add native void return types in Symfony 7.

nicolas-grekas commented 1 year ago

@PhilETaylor can you please send a PR to add the @return void annotation? That's enough to express the intent and fix the deprecation.