This PR was merged into the 3.2 branch.
Discussion
----------
[Serializer] Add deprecation missing from UPGRADE files
| Q | A
| ------------- | ---
| Branch? | 3.2
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no, simply mention one in upgrade files
| Tests pass? | yes
| Fixed tickets | N/A
| License | MIT
| Doc PR | N/A
Commits
-------
d681c1a Lines length should be 80 or less characters
597bbdc Lines length should be 80 or less characters
4514c1b [Serializer] Add deprecation missing from UPGRADE files
This PR was merged into the 3.2-dev branch.
Discussion
----------
[ExpressionLanguage] Making cache PSR6 compliant
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | N/A
| License | MIT
| Doc PR | [#7064](https://github.com/symfony/symfony-docs/pull/7064)
Adding Cache component compatible ParserCache in ExpressionLanguage component.
I hope you will find it useful :) I would like to make tests also
Commits
-------
a7352ff [ExpressionLanguage] Making cache PSR6 compliant
- Changed surrogate capability name to symfony
- Changed user agent of the BrowserKit Client to 'Symfony BrowserKit'
- Changed 'symfony2' to 'symfony' in timing templates
- Updated changelog and upgrade files
This PR was merged into the 3.2-dev branch.
Discussion
----------
[FrameworkBundle] removed the Security Core and Security CSRF component dependencies on FrameworkBundle
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no (except for people using FrameworkBundle without requiring symfony/symfony which should be pretty rare; and fixing this is easy by adding symfony/security-core and symfony/security-csrf explicitly)
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #15748 partially
| License | MIT
| Doc PR | n/a
Another PR to reduce the number of required dependencies on FrameworkBundle. This PR removes the Security Core and CSRF components from the list.
Commits
-------
d703784 [FrameworkBundle] removed the Security Core and Security CSRF component dependencies on FrameworkBundle
This PR was merged into the 3.2-dev branch.
Discussion
----------
[FrameworkBundle] removed the Templating component dependency on FrameworkBundle
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no (except for people using FrameworkBundle without requiring symfony/symfony which should be pretty rare; and fixing this is easy by adding symfony/templating explicitly)
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #15748 partially
| License | MIT
| Doc PR | n/a
Another PR to reduce the number of required dependencies on FrameworkBundle. This PR removes the Templating component from the list.
I made most of the work in previous version, so this change is really just about adding a good error message when templating is not enabled. For the record, this is also in the path of making possible to use Symfony with Twig without using the Templating component indirection (I think that this is in fact the last step).
Commits
-------
b3de62f [FrameworkBundle] removed the Templating component dependency on FrameworkBundle
This PR was squashed before being merged into the 3.2-dev branch (closes#19257).
Discussion
----------
[Validator][Choice] Make strict the default option for choice validation
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | #18973
| License | MIT
| Doc PR | -
This is just the WIP as there are two options.
1. Just change default which would only possible to introduce in 4.x or in 3.2 if this BC break is considered as acceptable
2. Add a new option e.g. `strictComparison` which defaults to true in 4.x and deprecate the usage of the strict option for 3.2.
3. Just deprecate strict = false and remove the option but I would be against that as we remove flexibility which might be wanted.
As per discussion I went ahead with option 3. We can then still decide if we want to remove the option entirely or eventually reenable setting strict to false in a later release.
Commits
-------
177c513 [Validator][Choice] Make strict the default option for choice validation
