* 5.1:
[Filesystem] fix for PHP 8
[Cache] fix DBAL v3 compat
Bump Symfony version to 5.1.7
Update VERSION for 5.1.6
Update CHANGELOG for 5.1.6
Bump Symfony version to 4.4.15
Update VERSION for 4.4.14
Update CHANGELOG for 4.4.14
Bump Symfony version to 3.4.46
Update VERSION for 3.4.45
Update CONTRIBUTORS for 3.4.45
Update CHANGELOG for 3.4.45
* 4.4:
[Filesystem] fix for PHP 8
[Cache] fix DBAL v3 compat
Bump Symfony version to 4.4.15
Update VERSION for 4.4.14
Update CHANGELOG for 4.4.14
Bump Symfony version to 3.4.46
Update VERSION for 3.4.45
Update CONTRIBUTORS for 3.4.45
Update CHANGELOG for 3.4.45
This PR was merged into the 5.2-dev branch.
Discussion
----------
[HttpFoundation][Cache][Messenger] Replace redis "DEL" commands with "UNLINK"
| Q | A
| ------------- | ---
| Branch? | master |
| Bug fix? | no
| New feature? | no |
| Deprecations? | no |
| Tickets | |
| License | MIT|
| Doc PR | |
This PR replaces DEL Command with UNLINK command.
Details about UNLINK can be found here https://redis.io/commands/unlink .
As noticed here redis/redis#1748 (comment) this will not change the behavior.
As there is no check of Redis version included, it will break Redis Versions < 4.0 through.
As Redis 4.0 was released on 2017-07-14 and Redis 3 went EOL with the Redis 5 on 2018-10-17, I don't expect this being an issue.
With redis 4.0 there is a new unlink command intruded ( https://redis.io/commands/unlink ) with is a smarter version of del() as it deletes keys in O(1) and frees the memory in background.
See also http://antirez.com/news/93 and redis/redis#1748
This won't change the behavior but only the memory usage as clarified here: redis/redis#1748 (comment) which shouldn't be an issue with most Magento instances
With this, I recommend replacing DEL operations with UNLINK operations.
Commits
-------
91a44524ff [HttpFoundation][Cache][Messenger] Replace redis "DEL" commands with "UNLINK"
* 5.1:
[ErrorHandler] Return false directly and remove unused variable
[OptionsResolver] Assert that the error type is valid in deprecations test
[OptionsResolver] Fix deprecation message access
[HttpClient] Allow bearer token with colon
[Form] Fix custom formats deprecation with HTML5 widgets
[Translator] Optional Intl dependency
[Contracts][Translation] Optional Intl dependency
[ErrorHandler] Escape JSON encoded log context
update missing translations arabic
[Yaml] simplify the test
fix test by letting mock throw the actual expected exception
* 4.4:
[ErrorHandler] Return false directly and remove unused variable
[OptionsResolver] Assert that the error type is valid in deprecations test
[HttpClient] Allow bearer token with colon
[Form] Fix custom formats deprecation with HTML5 widgets
[Translator] Optional Intl dependency
[Contracts][Translation] Optional Intl dependency
[ErrorHandler] Escape JSON encoded log context
update missing translations arabic
[Yaml] simplify the test
fix test by letting mock throw the actual expected exception
This PR was squashed before being merged into the 5.2-dev branch.
Discussion
----------
[lock] Provides default implementation when store does not supports the behavior
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| Deprecations? | yes
| Tickets | /
| License | MIT
| Doc PR | /
All stores does not provide the same behaviors. Some are blocking, some allows shared Locks, ...
Issue is: When people use `lock` to use a behavior that is not supported by the store, they get an `UnsuportedException`, but they don't have any way to know if the store supports or not the behavior they want to use.
ie: when using the FrameworkBundle
```yaml
framework:
lock: '%env(LOCK_DSN)%'
```
User (or bundle) can't use safely `$lock->acquire(true)` or `$lock->acquireRead()`.
Given it's very easy to provide an fallback implementation to those behavior, this PR
- use fallback implementation when store does not support the behavior
- deprecate the RetryTillSaveStore (not needed anymore)
Commits
-------
575b391b9b [lock] Provides default implementation when store does not supports the behavior
This PR was merged into the 5.2-dev branch.
Discussion
----------
[Notifier] Add Sendinblue notifier.
| Q | A
| ------------- | ---
| Branch? | master <!-- see below -->
| Bug fix? | no
| New feature? | yes <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets | no <!-- prefix each issue number with "Fix #", no need to create an issue if none exist, explain below instead -->
| License | MIT
| Doc PR | todo <!-- required for new features -->
Add Sendinblue SMS notifier bridge.
Commits
-------
e7300a8580 Add Sendinblue notifier.
This PR was merged into the 5.2-dev branch.
Discussion
----------
[Messenger] Fix misleading comment about time-limit
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | n/a
| License | MIT
| Doc PR | n/a
The current explanation of the time-limit option of the `messenger:consume` command is misleading as it lets you think that this is an enforced hard limit.
For instance, you may think that a command started with `--time-limit=10` will stop once 10 seconds are elapsed, no matter what.
Actually, two things happen:
- Once 10 seconds have elapsed, then the worker won't receive and handle any other message
- The worker will keep running until the currently handled message is fully handled so it can last way longer than 10 seconds, then it will stop.
I'm not sure this is behavior is actually a bug or not, but the current documentation does not describe the current behavior
Commits
-------
21176646e9 [Messenger] Fix misleading comment about time-limit
This PR was merged into the 5.2-dev branch.
Discussion
----------
[Translation] Allow Translatable objects to be used as strings
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
Allow Translatable objects to be used as strings.
Commits
-------
0ba206420e [Translation] Allow Translatable objects to be used as strings
This PR was merged into the 5.2-dev branch.
Discussion
----------
[PhpUnitBridge] Enable a maximum PHPUnit version to be set via SYMFONY_MAX_PHPUNIT_VERSION
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | none
| License | MIT
| Doc PR | symfony/symfony-docs#14286
This PR adds support for the `SYMFONY_MAX_PHPUNIT_VERSION` environment variable, letting users set the **maximum** version of PHPUnit to be considered when running the PHPUnit Bridge.
The use case here comes from testing WordPress using the library; as of the time of this ticket, [WordPress' core test suite does not yet support PHPUnit 8.x](https://core.trac.wordpress.org/ticket/46149). As a result, trying to run the WordPress core test suite with PHPUnit Bridge results in the following error under PHP 7.2 or newer:
> **Error:** Looks like you're using PHPUnit 8.3.5. WordPress requires at least PHPUnit 5.4 and is currently only compatible with PHPUnit up to 7.x.
Please use the latest PHPUnit version from the 7.x branch.
In this use case, the developer testing against WordPress would set `SYMFONY_MAX_PHPUNIT_VERSION=7.5` in their environment (or `phpunit.xml` file) and the PHPUnit Bridge would never go *above* that version (but would still be free to, for instance, load PHPUnit 6 when running under PHP 7.0).
Commits
-------
7877a5b488 [PhpUnitBridge] Enable a maximum PHPUnit version to be set via SYMFONY_MAX_PHPUNIT_VERSION
This PR was merged into the 4.4 branch.
Discussion
----------
[ErrorHandler] Return false directly and remove unused variable
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | https://github.com/symfony/symfony/issues/37848
| License | MIT
| Doc PR | -
To return true, $type and $log both need to be true. But to enter the condition, one of them has to be false.
I also spotted an unused variable below so I removed it.
Commits
-------
3933957d1a [ErrorHandler] Return false directly and remove unused variable
This PR was merged into the 4.4 branch.
Discussion
----------
[OptionsResolver] Assert that the error type is valid in deprecations test
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | no
| License | MIT
| Doc PR | no
A change in the code could cause a warning for example and still produce the expected number of errors and the expected last error. Checking the type of the error is a little bit better. The best would be to check all the expected deprecations one by one, maybe later? 😄
Commits
-------
926d18f2f9 [OptionsResolver] Assert that the error type is valid in deprecations test
This PR was squashed before being merged into the 5.2-dev branch.
Discussion
----------
Register the binary types as well
| Q | A
| ------------- | ---
| Branch? | 5.2
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix -
| License | MIT
| Doc PR | symfony/symfony-docs-
Binary versions were not working since they weren't registered
Commits
-------
96a0e5fca1 Register the binary types as well
