Wouter de Jong

Thanks for the hint @stof. I've edited my script slightly so we can use it as a CI check enforcing return types on interface: #49439 For now, that PR represents...

For everyone helping here: Thank you! Symfony 6.3 will be released with return types, either PHP ones or PHPdoc ones, for all methods in the bridges and components and for...

Thanks the feedback! I've forwarded this internally. Let's close here, as it isn't (and never will be) actionable by the community.

continued in #17597

On top of my message against convention based functionality in the other PR, I just learned that a *service* starting with a `.` makes it a hidden service (which only...

> As the previous PR was merged in 6.2, I hope this one can be released with it. Otherwise, 6.3 will be good too 😃 Feature freeze started 1.5 months...

No, for now the focus is on stabilizing Symfony 6.2 before the release. A 6.3 branch will be created once we're in RC phase for 6.2.

@vincentchalamon @chalasr I know. I wanted to post it here after finding it yesterday, but I forgot. Here is my proposal on the user provider stuff (based on my PR:...

> Adding some child user badge and making hasBadge()/getBadge() type-based instead of fqcn-based would work for me Unfortunately, making `getBadge()` aware of inheritance will make `getBadge()` return `list` instead of...

Optionally, we can also apply the same technique as used in Form types: use the FQCN as the *key* of a badge, but don't require it to be the FQCN...