This PR was merged into the master branch.
Commits
-------
9471a1c Added Luxembourgish translation for security component
Discussion
----------
Added Luxembourgish translation for security component
This PR was merged into the master branch.
Commits
-------
67d7423 Remove use of deprecated HttpKernel LoggerInterface
dca4528 [HttpKernel] Extend psr/log's NullLogger class
1e5a890 [Monolog] Mark old non-PSR3 methods as deprecated
91a86f8 [HttpKernel][Monolog] Add PSR-3 support to the LoggerInterface
Discussion
----------
[HttpKernel][MonologBridge] PSR-3 support
This enables PSR-3 support and monolog 1.3+. The first commit is the main part. The rest deals with deprecation of short-hand methods (warn/err/crit/emerg) that are fully expanded in PSR-3 (warning/error/critical/emergency).
The downside of deprecating them is that for bundles it's a bit harder to support older and newer versions. If that is too much of a hassle you can drop that for now and cherry pick the first commit.
The upside is that it forces people to move towards PSR-3 compatible stuff, which means eventually we could completely drop the LoggerInterface from the framework. In any case I think the documentation should only mention the `Psr\Log\LoggerInterface` and people should start hinting against that. The change should be done in core as well I suppose.
Anyway I wanted to throw this out there as it is to get feedback.
---------------------------------------------------------------------------
by stof at 2013-01-09T09:15:15Z
@Seldaek I also think you should change the typehint to use the PSR LoggerInterface in all classes using the logger
---------------------------------------------------------------------------
by Seldaek at 2013-01-09T09:54:55Z
OK updated according to all the feedback. I tested it in an app and it still seems to work so there shouldn't be any major issues.
---------------------------------------------------------------------------
by Seldaek at 2013-01-09T09:59:55Z
@fabpot if you merge please merge also the bundle PR, otherwise it won't be possible to update without conflict.
---------------------------------------------------------------------------
by frosas at 2013-01-10T14:59:20Z
I'm trying to understand why a `composer update` of a Symfony 2.1.* resulted in a fatal error. Shouldn't a stable version don't break like this?
As @olaurendeau points, why Symfony depends 1.* instead of 1.2.*? Or why Monolog 1.3 breaks its public interface (EDIT: I'm not sure about it)? Or why isn't this PR being merged (into branch 2.1) at the same time Monolog 1.3 is released?
Please, understand I'm not looking for who to blame, it's just I want to know if this situation is unexpected or if otherwise a `composer update` on a stable branch is not as innocent as it seems.
---------------------------------------------------------------------------
by stof at 2013-01-10T15:06:51Z
@frosas it cannot be merged into 2.1 as it is a BC break. The 2.1 branch has been updated to forbid Monolog 1.3 already
---------------------------------------------------------------------------
by Seldaek at 2013-01-10T15:11:58Z
@frosas you can blame me for releasing as 1.3.0 and not 2.0, but technically for monolog this isn't really a BC break, I just added an interface. The problem is due to the way it's used in symfony, it ended up as a fatal error. In any case the situation is now sorted out I think.
---------------------------------------------------------------------------
by frosas at 2013-01-10T15:26:43Z
@stof now I see this `>=1.0,<1.3-dev` change in the 2.1 branch. Now, shouldn't a new (2.1.7) version be released for all of us not in the dev minimum-stability?
@Seldaek then do you see feasible to rely only in X.Y.* versions to avoid this kind of errors?
---------------------------------------------------------------------------
by Seldaek at 2013-01-10T15:45:22Z
@frosas relying on X.Y.* is painful because you always need to wait until someone updates the constraint to get the new version. Of course using ~1.3 like in this PR means if I fuck up and break BC people will update to it, but that's a less likely occurrence than the alternative I think, so I would rather not use X.Y.*
---------------------------------------------------------------------------
by frosas at 2013-01-10T15:50:50Z
@Seldaek you are right about this, but I was thinking more in changing it only for the stable versions. EDIT: I mean, how often do you need a new feature in a branch you only apply fixes to?
---------------------------------------------------------------------------
by stof at 2013-01-10T15:57:32Z
@frosas Monolog and Symfony have separate release cycles. Foorcing Symfony users to use an old version of Monolog until they update to a new version of Symfony whereas the newer Monolog is compatible is a bad idea. Thus, as Monolog keeps BC, it does not maintain bugfix releases for all older versions (just like Twig does too). So it would also forbid you to get the fixes done in newer Monolog versions.
The incompatibility between Symfony 2.1 LoggerInterface and PSR-3 (whereas they expect exactly the same behavior and signature for methods with the same name) is unfortunate and is the reason why we get some issues here.
---------------------------------------------------------------------------
by frosas at 2013-01-10T16:21:06Z
@stof I appreciate you prefer to allow newer versions at the price of having to be constantly monitoring its changes to avoid breaks.
Another similar but safer strategy would be to stick to X.Y.* versions and upgrade to X.Y+1.* once the new version integration is tested, but I understand this is discutible in projects as close to Symfony as Monolog.
Returning to the issue, what do you say to release this 2.1.7 version? Or is it only me who is having issues here?
---------------------------------------------------------------------------
by stof at 2013-01-10T16:26:20Z
@frosas a minor release should not break BC when following smeantic versionning (Symfony warned about the fact it is not strictly followed for the first releases of 2.x). But as far as monolog is concerned, 1.3 is BC with 1.2.
---------------------------------------------------------------------------
by Seldaek at 2013-01-10T16:49:55Z
@frosas sorry I didn't get you still had the problem. I tagged a 2.1.7 of monologbundle which hopefully fixes your issue.
This PR was merged into the master branch.
Commits
-------
c6eb819 Created security.cs.xlf
Discussion
----------
[security][tranlation] Created Czech translation to Security
This PR was merged into the master branch.
Commits
-------
0b75f67 Security component Polish message translations
Discussion
----------
[Security] Polish message translations
Security component messages translated from English to Polish.
This PR was merged into the master branch.
Commits
-------
c06e627 Fixed some typos
Discussion
----------
FIxed some typos in the Spainsh translation of the Security component messages
Hi,
In order to show the most clear and less _"robotic"_ messages in Spanish, I've fixed some typos and some incorrect translations in the Spanish translation file of the Security component.
Christian.
This PR was merged into the master branch.
Commits
-------
e84a8d0 fixed some small issues with grammar and used terminology
Discussion
----------
fixed some small issues with grammar and used terminology
This PR was merged into the master branch.
Commits
-------
d5825aa slovenian translations of security component added
Discussion
----------
Slovenian translations of security component added
This PR was merged into the master branch.
Commits
-------
d6f972b Created Slovak translation to Security
Discussion
----------
[security][tranlation] Created Slovak translation to Security
This PR was merged into the master branch.
Commits
-------
6ae8ca8 Update src/Symfony/Component/Security/Resources/translations/security.es.xlf
Discussion
----------
Update src/Symfony/Component/Security/Resources/translations/security.es...
....xlf
This PR was merged into the master branch.
Commits
-------
9b8428d [security][tranlation]Fixed spanish translation
Discussion
----------
[security][tranlation]Fixed spanish translation
This PR was merged into the master branch.
Commits
-------
0b5177b added italian translations
Discussion
----------
added italian translations for the security component
---------------------------------------------------------------------------
by matteosister at 2013-01-10T14:22:54Z
not sure if the file should be named **security.it_IT.xlf** or **security.it.xlf**
---------------------------------------------------------------------------
by fabpot at 2013-01-10T14:25:49Z
security.it.xlf
---------------------------------------------------------------------------
by matteosister at 2013-01-10T14:31:14Z
ok, renamed the files, and squashed the pr to a single commit!
Thanks @fabpot!
This PR was squashed before being merged into the master branch (closes#6660).
Commits
-------
45c8682 [Security][Translation]Created fr translation for Security
Discussion
----------
[Security][Translation]Created fr translation for Security
adds french translations for the security component
This PR was merged into the master branch.
Commits
-------
c3a6659 [Security] added Hungarian translations for exception messages
Discussion
----------
[Security] added Hungarian translations for exception messages
This PR was merged into the master branch.
Commits
-------
2f51961 Created de translation for Security
Discussion
----------
[Security][Translation]Created de translation for Security
This PR was merged into the master branch.
Commits
-------
e35998f Translated to Romanian
Discussion
----------
[Security] Translated to Romanian
Added Romanian version for Security messages.
Thanks!
This PR was merged into the master branch.
Commits
-------
ff5ba38 Created PT_BR translation for Security
Discussion
----------
[Security][Translation]Created PT_BR translation for Security
Added the PT_BR strings for Security strings.
This PR was merged into the master branch.
Commits
-------
68257d3 Enhanced the triggering of E_USER_DEPRECATED errors
Discussion
----------
Enhanced the triggering of E_USER_DEPRECATED errors
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Deprecations: no
Symfony2 tests pass: yes
Fixes the following tickets: none
- Removed useless error handlers around FormEvent as the triggering has
been fixed in it.
- Enhanced the triggering of deprecation errors for places where the BC
method provide some user logic needing to be converted to a new way.
For instance, AbstractType should trigger the error when the type extending it overwrites the deprecated methods instead of ``setDefaultOptions``, which was not the case previously.
- Enhanced the deprecation messages to mention the replacement whenever
possible.
---------------------------------------------------------------------------
by stof at 2013-01-10T01:23:49Z
@fabpot should I remove ``Symfony\Component\Form\Test\DeprecationErrorHandler::getFormEvent`` ? It is not used anymore in the testsuite and is not needed anymore as the constructor of FormEvent does not trigger the deprecation erronously.
---------------------------------------------------------------------------
by fabpot at 2013-01-10T07:24:02Z
@stof: yes, remove it then. Thanks.
---------------------------------------------------------------------------
by stof at 2013-01-10T08:23:14Z
done
