Closed PhilETaylor closed 1 year ago
Can you please a look at the conversation at https://github.com/doctrine/DoctrineMigrationsBundle/pull/492?
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?
The difficulty is that we don't plan a new major at the moment.
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.
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.
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.
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.
"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.
"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.
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.
Also: we won't add native void return types in Symfony 7.
@PhilETaylor can you please send a PR to add the @return void
annotation? That's enough to express the intent and fix the deprecation.