Ignore Symfony 5 bumps for now

[ChristophWurst]

Dependabot shall send us 4.x updates instead.

[CarlSchwan]

Make sense but I wonder how we handle api break in our 3rdparty lib that are exposed to 3rd party apps in general. We need at some point to update to symfony 5 once symfony 4 is eol

[ChristophWurst]

Make sense but I wonder how we handle api break in our 3rdparty lib that are exposed to 3rd party apps in general. We need at some point to update to symfony 5 once symfony 4 is eol

Excellent question. We had the same dilemma with dbal. Strictly speaking apps should never depend on any external dependencies of Nextcloud. In reality they do. For dbal we still have some public APIs that leak dbal classes. For Symfony the public API doesn't leak much, except for the already deprecated event dispatcher.

However, what will potentially blow up is all the CLI commands that directly use Symfony. For those we have to define a proper abstract public API without any direct ties on Symfony. Then apps can migrate to this and we can swap the Symfony version without too much hassle.

@skjnldsv could you possibly put this onto the todo for 24? We need a solid CLI command API to clean this up.