DBAL 2 is still more popular than we'd like it to be, despite being officially EOL for almost a year now. My plan was to drop support in Symfony 7. I didn't want apps to be locked on a non-LTS release because they haven't upgraded to DBAL 3 yet (for whatever reason).

I won't block the change, it's just that I think we should've talked about that. 🙂

[HttpFoundation] Deprecate passing invalid URI to Request::create

Fixes: #47084

Passing an invalid URI to Request::create triggers an undefined code path. In PHP7 the false value returned by parse_url would quietly be treated as a an array through type coercion leading to unexpected results. In PHP8 this triggers a deprecation exposing the bug.

[Security] Add logout configuration for Clear-Site-Data header

Removed @internal tag on TraceableAuthenticator::getAuthenticator()

[TwigBridge] Fix TwigDataCollector::getTime() return type

[Messenger] Fix TransportNamesStamp deserialization

| Q | A | ------------- | --- | Branch? | 6.2 | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | https://github.com/symfony/symfony/issues/31490#issuecomment-1439927253 | License | MIT | Doc PR | n/a

Currently, when ones use TransportNameStamp the following exception occurs:

In Serializer.php line 125:

  [Symfony\Component\Messenger\Exception\MessageDecodingFailedException]
  Could not decode stamp: Cannot create an instance of "Symfony\Component\Messenger\Stamp\TransportNamesStamp" from serialized data because its constructor requires parameter "transports" to be present.

In AbstractNormalizer.php line 384:

  [Symfony\Component\Serializer\Exception\MissingConstructorArgumentsException]
  Cannot create an instance of "Symfony\Component\Messenger\Stamp\TransportNamesStamp" from serialized data because its constructor requires parameter "transports" to be present.

This PR renames TransportNamesStamp constructor argument in order to match the accesor method (getTranspdortNames) so that deserialization work.

I know this is technically a BC break but as far as I can tell the feature can not currently work this way and also named arguments are not covered by Symfony's BC if I remember correctly.

Update CHANGELOG for 5.4.21

Update CONTRIBUTORS for 5.4.21

Update VERSION for 5.4.21

Merge pull request #49558 from fabpot/release-5.4.21

released v5.4.21

Bump Symfony version to 5.4.22

Update CHANGELOG for 6.2.7

Update VERSION for 6.2.7

Merge pull request #49559 from fabpot/release-6.2.7

released v6.2.7

Bump Symfony version to 6.2.8

Fix typo

Fix typo

[DependencyInjection] Fix dumping array of enums parameters

bug #49578 [DependencyInjection] Fix dumping array of enums parameters (fancyweb)

This PR was merged into the 5.4 branch.

Discussion

[DependencyInjection] Fix dumping array of enums parameters

| Q | A | ------------- | --- | Branch? | 5.4 | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | https://github.com/symfony/symfony/issues/49505 | License | MIT | Doc PR | -

Commits

97c5874320 [DependencyInjection] Fix dumping array of enums parameters

bug #49546 [TwigBridge] Fix TwigDataCollector::getTime() return type (fancyweb)

This PR was merged into the 6.3 branch.

Discussion

[TwigBridge] Fix TwigDataCollector::getTime() return type

| Q | A | ------------- | --- | Branch? | 6.3 | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | - | License | MIT | Doc PR | -

Ref https://github.com/symfony/symfony/pull/49348

It generates implicit incompatible float to int conversion deprecations.

Commits

29e2e13f6b [TwigBridge] Fix TwigDataCollector::getTime() return type

bug #49541 [Security] Remove @internal tag on TraceableAuthenticator::getAuthenticator() (florentdestremau)

This PR was merged into the 5.4 branch.

Discussion

[Security] Remove @internal tag on TraceableAuthenticator::getAuthenticator()

| Q | A | ------------- | --- | Branch? | 5.4 | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | See #49015 | License | MIT

Following the discussion in #49015 I made this PR

Commits

0a8ba937b7 Removed @internal tag on TraceableAuthenticator::getAuthenticator()

I don't think that this is the right approach. Why do we need the Symfony\Bridge\Monolog\Logger class at all? It is used to find the debug logger which is buried somewhere in the log processor stack. If we wire the debug logger into the profiler directly, the whole class would be obsolete.

All right, pushing to my branch doesn't work either at the moment. I guess, we need to wait until GitHub got rid of its little hiccup. 😑

We need to tell people to use a verbatim version string, but all DBAL APIs that would deliver that string are internal.

I've updated my PR with detailed instructions for MySQL, MariaDB and Postgres on how to get the version string without DBAL. For other platforms, the version string is currently irrelevant, but I've documented the use of the internal APIs for that matter, although I'm not very comfortable with such APIs appearing in the documentation.

add mb_check_encoding with array value

bug #426 add mb_check_encoding with array value (jeremyFreeAgent)

This PR was squashed before being merged into the 1.28-dev branch.

Discussion

add mb_check_encoding with array value

I tried to address the https://github.com/symfony/polyfill/issues/422 issue.

First time on that project. I'm not sure about what I've done because I'm afraid we cannot do anything for PHP <7.2.

Commits

970d030 add mb_check_encoding with array value

Update return type for IntlDateFormatter::format()

Since PHP 8.0.0, the method is documented as having a string|false return (see https://github.com/php/php-src/blob/php-8.0.0/ext/intl/dateformat/dateformat.stub.php#L99-L104), this updates the polyfill to match the native signature which can help avoid static analysis issues where the polyfill has a wider return type than the native implementation.

minor #430 Update return type for IntlDateFormatter::format() (mbabker)

This PR was merged into the 1.28-dev branch.

Discussion

Update return type for IntlDateFormatter::format()

Since PHP 8.0.0, the method is documented as having a string|false return (see https://github.com/php/php-src/blob/php-8.0.0/ext/intl/dateformat/dateformat.stub.php#L99-L104), this updates the polyfill to match the native signature which can help avoid static analysis issues where the polyfill has a wider return type than the native implementation.

Commits

ae54993 Update return type for IntlDateFormatter::format()

Since PHP 8.0.0, the method is documented as having a string|false return (see https://github.com/php/php-src/blob/php-8.0.0/ext/intl/dateformat/dateformat.stub.php#L99-L104), this updates the polyfill to match the native signature which can help avoid static analysis issues where the polyfill has a wider return type than the native implementation.

Update return type for IntlDateFormatter::format()

Since PHP 8.0.0, the method is documented as having a string|false return (see https://github.com/php/php-src/blob/php-8.0.0/ext/intl/dateformat/dateformat.stub.php#L99-L104), this updates the polyfill to match the native signature which can help avoid static analysis issues where the polyfill has a wider return type than the native implementation.

minor #430 Update return type for IntlDateFormatter::format() (mbabker)

This PR was merged into the 1.28-dev branch.

Discussion

Update return type for IntlDateFormatter::format()

Since PHP 8.0.0, the method is documented as having a string|false return (see https://github.com/php/php-src/blob/php-8.0.0/ext/intl/dateformat/dateformat.stub.php#L99-L104), this updates the polyfill to match the native signature which can help avoid static analysis issues where the polyfill has a wider return type than the native implementation.

Commits

ae54993 Update return type for IntlDateFormatter::format()

Good catch, thanks @mbabker.