3.x not yet compatible with symfony 8.x

[alcohol]

symfony/http-foundation 8.x removed support for calling get on the request object:

Remove Request::get(), use properties ->attributes, query or request directly instead

This is still being used by the resolver controller:

LiipImagineBundle/src/Controller/ImagineController.php

Line 62 in fbd2e18

$resolver = $request->get('resolver');

Since there is no direct requirement on symfony/http-foundation it is possible to install the incompatible version alongside, because the framework-bundle allows both 7.x and 8.x

[alcohol]

@dbu how can I help? 🤓

[dbu]

sorry for being non-responsive. right, i remember that one, we should be explicit where we expect the parameter to come from. as the routers are limited to GET i think we can adjust this code to explicitly look in the get parameters without risking a backwards compatibility break.

this should be done against the 2.x branch, as that claims its compatible with symfony 8. we seem to lack an important test here, as we do test with symfony 8.

glad if you can do a pull request with the change, and ideally also a test that fails without the change to make sure we cover that controller.

[alcohol]

Well the 2.x branch passes because the issue has been resolved already in the 2.x branch. But this was never merged upstream into 3.x it seems. Is the 3.x branch still maintained? We've been using it for a long time already.

[dbu]

ah sorry, now i got what you are asking. i started upmerging 2.x to 3.x in #1653 . there have been a ton of conflicts. phpstan is currently still rather unhappy.

if you have some time to look into the build and propose fixes, that certainly would help. (a lot is hopefully mistakes in the service configuration because of the rewrite from xml to php this needs to be manually compared)

[alcohol]

I'm not sure how you want to proceed with that. From what I can tell, 3.x is is rather quite behind on 2.x. Do you want it rebased, resolving the conflicts step by step? Cause that seems like a very tedious and lengthy process at this point.

[dbu]

indeed, rebasing would be problematic, as it would change all commits in the 3.x branch, and likely give similar conflicts multiple times for consequitive commits.

#1653 is branched off 3.x and i merged 2.x into it. i solved the merge conflicts, but there is some drift that does not result in conflicts. those need to be adressed. if we can fix those, future merges of 2.x to 3.x should work out fine again.