[Form] Moved the Validator component to the suggest section

There is no hard dependency to the Validator component.
Fixed constraint requirements for Doctrine Common
[Security] Regenerated the ACL SQL schema with the latest Doctrine version
[HttpFoundation] Restore compliance with RFC2324
Add missing backtick to CHANGELOG-2.1
merged branch xanido/master (PR #3558)

Commits
-------

afd708e Add missing backtick to CHANGELOG-2.1

Discussion
----------

Fix a typo in CHANGELOG-2.1

Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: -
Fixes the following tickets: -
Todo: -
merged branch drak/patch-2 (PR #3556)

Commits
-------

0761b8a [HttpFoundation] Restore compliance with RFC2324

Discussion
----------

[HttpFoundation] Restore compliance with RFC2324

Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
merged branch stof/composer_deps (PR #3553)

Commits
-------

f26c1ce Fixed constraint requirements for Doctrine Common
011791d [Form] Moved the Validator component to the suggest section

Discussion
----------

Composer deps

There is no hard dependency to the Validator component in the Form, as said on Twitter when @harikt tried to use it. I kept the Locale component as a requirement as it is used by the LanguageTyep, CountryType and LocaleType which will be registered when using the CoreExtension.

The constraints for Doctrine deps are fixed too: adding an upper bound everywhere as we don't know the future to guarantee the compatibility (and for instance, 2.0.9 and lower were not compatible with ORM 2.2 as we had to fix the bundle), and the bridge is compatible with Common 2.2 too, not only with 2.1.

I found 2 other places where the dependencies should be discussed:

- the Validator component marks a hard dependency to Doctrine Common for its annotation reader. There is a dependency only when using annotation so it should not be a hard requirement IMO but a suggestion. the issue is that the [ValidatorFactory](https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Validator/ValidatorFactory.php) (not used by the framework itself) will add an annotation loader when relying on the default value of the arguments, which means that people that don't take care will need Common. Would it make sense to change the default so that Common is needed only when the user explicitly asks to use annotations ? Moving Common from require to suggest would make it easier for people using the Validator component standalone if they don't use annotations
- the Security component suggests the Finder and ClassLoader components. But these ones are only used by the [dev script](https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Security/Acl/Resources/bin/generateSql.php) used to generate the SQL schema shipped in the component. Does it really make sense to list them as people cloning the component should probably never use this script (which alters the files in the component) ?

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

by fabpot at 2012-03-11T08:14:46Z

+1 for removing Doctrine Common as a required dependency for the Validator component.

+1 for removing ClassLoader and Finder from the Security suggestions.
merged branch stof/acl_schemas (PR #3554)

Commits
-------

919eee4 [Security] Regenerated the ACL SQL schema with the latest Doctrine version

Discussion
----------

[Security] Regenerated the ACL SQL schema with the latest Doctrine version

This regenerates the SQL schemas for all platforms supported by Doctrine as some changes were made in the DBAL code since the previous run of the script and a new platform has been added.
merged branch Engerim/patch-1 (PR #3538)

Commits
-------

3fd9003 Update src/Symfony/Component/Security/Acl/Permission/MaskBuilder.php

Discussion
----------

Changed return Tags from PermissionBuilder to MaskBuilder
merged branch johnnypeck/patch-2 (PR #3536)

Commits
-------

99079ba Very small semantic changes improving understanding and readability.

Discussion
----------

Very small semantic changes improving understanding and readability.

The "may or may not" change may seem pedantic but it quantifies the use of the field; obviously a boolean is true or not but "may not be empty" made me wonder about it's intent so clarification seemed appropriate.

Change "return" to "returns" as the rest of the code in the class uses this syntax.

Change "contains" to "contain" in an exception message.
merged branch hason/classloader (PR #3529)

Commits
-------

1ec075d [ClassLoader] Fixed version compare
8fb529c [ClassLoader] Fixed ClassMapGenerator and added suport for traits

Discussion
----------

[ClassLoader] Fixed ClassMapGenerator and added suport for traits

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

by hason at 2012-03-08T10:49:53Z

@fabpot, @Seldaek ``PHP_VERSION_ID`` or ``version_compare``?

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

by Seldaek at 2012-03-08T11:42:20Z

Ultimately @fabpot can call it, but I'm pro version_compare because it's just typically used for those checks, which may not make it more readable but makes it less WTF since it's a common pattern.

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

by drak at 2012-03-08T13:43:18Z

I prefer `version_compare()` with `phpversion()` as it's way more readable and obvious what it is.

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

by fabpot at 2012-03-08T17:06:25Z

+1 for `version_compare()`

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

by hason at 2012-03-09T07:19:10Z

@fabpot done
[CssSelector] fixed CssSelector::toXPath() when the CSS selector is an empty string
[Security]replaced acl:init command with postGenerateSchema listener
[SecurityBundle] Improve the init:acl command
merged branch vicb/acl (PR #3560)

Commits
-------

6d27aec [SecurityBundle] Improve the init:acl command
e809458 [Security]replaced acl:init command with postGenerateSchema listener

Discussion
----------

[WIP][Security]replaced acl:init command with postGenerateSchema listener

Attempt to fix #2091.

The code is from @schmittjoh (see #1313) but was never merged.

The difference is that the `init:acl` command has not been dropped in order to overcome [the limitations](https://github.com/symfony/symfony/pull/1313#issuecomment-1387091) described by @stof. @stof do you think this is ok ?

Left to fix:

* Using the code from this PR, the generated migration does not drop the tables but still alter them,

@stof you know this part of the code far better than me. I would appreacite your feedback on this PR and any hint on solving the remaining item. Thanks.
fixed CS
merged 2.0
fixed CS
Merge remote-tracking branch 'upstream/master'

* upstream/master:
  fixed CS
  fixed CS
  [SecurityBundle] Improve the init:acl command
  [Security]replaced acl:init command with postGenerateSchema listener
  [CssSelector] fixed CssSelector::toXPath() when the CSS selector is an empty string
  Add missing backtick to CHANGELOG-2.1
  [HttpFoundation] Restore compliance with RFC2324
  [Security] Regenerated the ACL SQL schema with the latest Doctrine version
  Fixed constraint requirements for Doctrine Common
  [Form] Moved the Validator component to the suggest section
  [BrowserKit] Fixed Client->back/forward/reload() not keeping all request attributes
  [Locale] Prevent empty bundle
  Update src/Symfony/Component/Security/Acl/Permission/MaskBuilder.php
  Very small semantic changes improving understanding and readability.
  [ClassLoader] Fixed version compare
  [ClassLoader] Fixed ClassMapGenerator and added suport for traits