[Security] Add PHPDoc to AuthenticationEvents
Correct comment in NativeSessionStorage regarding session.save_handler

It's save_handler, not save_handlers.
merged branch igorw/session-save-handler-comment (PR #6922)

This PR was merged into the 2.1 branch.

Commits
-------

d6c0455 Correct comment in NativeSessionStorage regarding session.save_handler

Discussion
----------

Correct comment in NativeSessionStorage regarding session.save_handler

It's save_handler, not save_handlers.
Replaced call that triggers deprecated error
merged branch dlsniper/validator-deprecation (PR #6929)

This PR was merged into the master branch.

Commits
-------

d0341e8 Replaced call that triggers deprecated error

Discussion
----------

[Validator][ChoiceValidator] Replaced call that triggers deprecated error

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | ~
| License       | MIT
| Doc PR        | ~

This removes the deprecation warnings from the ChoiceValidator.
Remove executable bit from all PHP files
merged branch TravisCarden/master (PR #6933)

This PR was merged into the master branch.

Commits
-------

924c256 Remove executable bit from all PHP files

Discussion
----------

Remove executable bit from all PHP files

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   |
| Fixed tickets |
| License       | MIT
| Doc PR        |

Apologies if I haven't got the protocol quite right here. This is my first interaction with this project.

By the way, I've noticed a non-trivial number of pull requests to remove executable bits. Could there be an automated test to prevent files getting into the repo with them on in the first place?
updated the branch alias in composer files
Update `composer.json` files: - to allow versions ~2.2 (>=2.2,<3.0) of Doctrine DBAL, ORM & Common - fixed Propel1 versions difference between main and bridge files - fixed Twig versions difference between main and bridge files - to allow versions ~1.11 (>=1.11,<2.0) of Twig - fixed Locale ext-intl version to accept all, not non-existing version
merged branch stloyd/feature/doctrine_versions (PR #6632)

This PR was submitted for the master branch but it was merged into the 2.2 branch instead (closes #6632).

Commits
-------

a1c0ff5 Update `composer.json` files: - to allow versions ~2.2 (>=2.2,<3.0) of Doctrine DBAL, ORM & Common - fixed Propel1 versions difference between main and bridge files - fixed Twig versions difference between main and bridge files - to allow versions ~1.11 (>=1.11,<2.0) of Twig - fixed Locale ext-intl version to accept all, not non-existing version

Discussion
----------

Update `composer.json` files

---------------------------------------------------------------------------

by fabpot at 2013-01-09T17:55:54Z

When will Doctrine 2.4 be released? If not in the next couple of weeks, this PR cannot be merged as we need to ship Symfony 2.2 with a stable version of Doctrine.

---------------------------------------------------------------------------

by stof at 2013-01-09T18:13:59Z

@fabpot This allows to use Doctrine 2.4. It does not require to use 2.4. Actually, as Doctrine releases are BC, I would even vote for using ``~2.2`` as requirement

---------------------------------------------------------------------------

by fabpot at 2013-01-10T08:18:52Z

If the Doctrine is fine with `~2.2`, let's do that. @beberlei Can you confirm?

---------------------------------------------------------------------------

by stloyd at 2013-01-10T08:30:19Z

As Doctrine latest release is `2.3.2` maybe for Symfony `2.2` we should increase to `~2.3` not `~2.2` ?

---------------------------------------------------------------------------

by stof at 2013-01-10T09:15:00Z

@stloyd Why should we force using 2.3 when we don't require any of the 2.3 features ? Composer will use the most recent package matching the constraint anyway, so 2.2 will not be used unless someone forbids 2.3 in another package.

---------------------------------------------------------------------------

by stloyd at 2013-01-29T19:24:09Z

@fabpot ping
Fix a deprecated method call in the tests
merged branch vicb/fixvalid (PR #6938)

This PR was submitted for the master branch but it was merged into the 2.2 branch instead (closes #6938).

Commits
-------

b279dcb [Validator] Fix a deprecated method call in the tests

Discussion
----------

[Validator] Fix a deprecated method call in the tests

BUG FIX - Travis happier ?

---------------------------------------------------------------------------

by stloyd at 2013-02-01T12:23:18Z

This should go to `2.2` I guess... =)

---------------------------------------------------------------------------

by vicb at 2013-02-01T12:25:43Z

Well there has been no official announcement for the 2.2 branch I think ?
I hope that some PR pending for master will go into 2.2 anyway ?

/cc @fabpot

---------------------------------------------------------------------------

by vicb at 2013-02-01T12:38:35Z

C'mon Travis, aren't you allowed to fail for 5.5 ?

---------------------------------------------------------------------------

by stloyd at 2013-02-01T12:43:42Z

@vicb error != failed ;-) Yet I agree, that now it's more confusing than before this new status...

---------------------------------------------------------------------------

by fabpot at 2013-02-01T13:27:11Z

I will merged it into 2.2. 2.2 is entering the RC phase, so no more modifications will be merged.
Classcollectionloader: fix traits + enhancements
merged branch vicb/classcollectionloader (PR #6258)

This PR was submitted for the master branch but it was merged into the 2.2 branch instead (closes #6258).

Commits
-------

d4acd6d Classcollectionloader: fix traits + enhancements

Discussion
----------

Classcollectionloader: fix traits + enhancements

Commits:

- some tweaks
- generates smaller cache files (20% decrease for the SE)
- fix traits dependency - thanks php for consistency https://bugs.php.net/bug.php?id=61554

---------------------------------------------------------------------------

by vicb at 2012-12-11T07:56:07Z

@stloyd @fabpot thanks for the useful reviews, everything should be fixed now.

---------------------------------------------------------------------------

by vicb at 2012-12-11T10:03:48Z

Should be ready.

---------------------------------------------------------------------------

by vicb at 2013-01-15T21:05:42Z

@fabpot I initially marked this PR for 2.3 but it contains a fix for traits, should you merge it ?

---------------------------------------------------------------------------

by vicb at 2013-01-23T20:09:32Z

@fabpot could this be in 2.2 ?

---------------------------------------------------------------------------

by vicb at 2013-02-01T14:07:08Z

@fabpot fixed
renamed some classes and Twig functions to more descriptive names (refs #6871)

HttpContentRenderer has been renamed to FragmentHandler.
The RendererStrategy subnamespace has been renamed to Fragment.
The strategy classes now have Fragment in their names.
ProxyRouterListener has been renamed to FragmentListener
The router_proxy configuration entry has been renamed to fragments.
merged branch fabpot/renderer-renaming (PR #6925)

This PR was submitted for the master branch but it was merged into the 2.2 branch instead (closes #6925).

Commits
-------

0586643 renamed some classes and Twig functions to more descriptive names (refs #6871)

Discussion
----------

renamed some classes and Twig functions to more descriptive names (refs #6871)

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #6871
| License       | MIT
| Doc PR        | symfony/symfony-docs#2205

Todo:

 - [x] update the docs

In #6871, @kriswallsmith wondered if the names used for the ESI/HIncludes sub-framework were meaningful enough.

I agree that this was not the case and I propose to remove the notion of **sub-requests** in favor of **fragments**. This sub-framework is a way to render fragments of a resource (the fact that it's done via another request is an implementation detail).

With that decision, all names can be renamed and are probably more meaningful. Some examples:

* `HttpContentRenderer` -> `FragmentHandler`
* `RouterProxyListener` -> `FragmentListener`
* `router_proxy` -> `fragments` (configuration entry)
* `DefaultRenderingStrategy` -> `InlineFragmentRenderer`

---------------------------------------------------------------------------

by fabpot at 2013-01-31T09:50:14Z

I forgot to mention that this renaming will also probably help documenting the feature as understanding the notion of a fragment is probably easier.

---------------------------------------------------------------------------

by Tobion at 2013-01-31T14:18:40Z

I'd like to say again that the word `render` in `FragmentRenderingStrategy` does not fit because it's not about rendering (that's left to the templating) of a fragment.
I suggest to rename it to `FragmentInclusionStrategy` because it defines the strategy to include the fragment.
This is also consistent with every strategy there is:
- ESI: `<esi:include`
- SSI: `<!--#include file="header.shtml" -->`
- hinclude (even in the name)
- inline (similar to phps `include()`)

---------------------------------------------------------------------------

by fabpot at 2013-01-31T14:48:07Z

I've just renamed `FragmentRenderer` to `FragmentHandler` and strategies like `EsiFragmentRenderingStrategy` to `EsiFragmentRenderer` (and everything is put into a new `Fragment` sub-namespace).

---------------------------------------------------------------------------

by fabpot at 2013-01-31T21:11:44Z

I've reverted the Twig function name change as the current name is more expressive with its arguments: `render(controller(...))` or `render_esi(url(...))`.
[FrameworkBundle] fixed typo
[HttpKernel] fixed regression when rendering an inline controller and passing some objects  (closes #6822)
Add Arabic translations.
merged branch mahmouds/arabic-support-master (PR #6944)

This PR was submitted for the master branch but it was merged into the 2.2 branch instead (closes #6944).

Commits
-------

2b850b5 [Form] [Validator] [Security] Add Arabic translations.

Discussion
----------

[Form] [Validator] [Security] Add Arabic translations.

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | ~
| License       | MIT
| Doc PR        | ~