Merge branch '2.7' into 2.8

Author: wouterj

book/testing.rst

@@ -17,8 +17,9 @@ it has its own excellent `documentation`_.
 
 .. note::
 
-    It's recommended to use the latest stable PHPUnit version (you will have
-    to use version 4.2 or higher to test the Symfony core code itself).
+    It's recommended to use the latest stable PHPUnit version, `installed as
+    PHAR`_ (you will have to use version 4.2 or higher to test the Symfony core 
+    code itself).
 
 Each test - whether it's a unit test or a functional test - is a PHP class
 that should live in the ``Tests/`` subdirectory of your bundles. If you follow
@@ -921,3 +922,4 @@ Learn more
 
 .. _`$_SERVER`: http://php.net/manual/en/reserved.variables.server.php
 .. _`documentation`: https://phpunit.de/manual/current/en/
+.. _`installed as PHAR`: https://phpunit.de/manual/current/en/installation.html#installation.phar

contributing/code/patches.rst

@@ -14,8 +14,7 @@ Before working on Symfony, setup a friendly environment with the following
 software:
 
 * Git;
-* PHP version 5.3.9 or above;
-* `PHPUnit`_ 4.2 or above.
+* PHP version 5.3.9 or above.
 
 .. caution::
 
@@ -365,4 +364,3 @@ before merging.
 .. _`fabbot`: http://fabbot.io
 .. _`PSR-1`: http://www.php-fig.org/psr/psr-1/
 .. _`PSR-2`: http://www.php-fig.org/psr/psr-2/
-.. _PHPUnit: https://phpunit.de/manual/current/en/installation.html

contributing/code/standards.rst

@@ -160,7 +160,7 @@ Structure
 
 * Declare public methods first, then protected ones and finally private ones.
   The exceptions to this rule are the class constructor and the ``setUp`` and
-  ``tearDown`` methods of PHPUnit tests, which should always be the first methods
+  ``tearDown`` methods of PHPUnit tests, which must always be the first methods
   to increase readability;
 
 * Declare all the arguments on the same line as the method/function name, no
@@ -169,11 +169,11 @@ Structure
 * Use parentheses when instantiating classes regardless of the number of
   arguments the constructor has;
 
-* Exception and error message strings should be concatenated using :phpfunction:`sprintf`.
+* Exception and error message strings must be concatenated using :phpfunction:`sprintf`;
 
-* Calls to :phpfunction:`trigger_error` with type ``E_USER_DEPRECATED`` should be
+* Calls to :phpfunction:`trigger_error` with type ``E_USER_DEPRECATED`` must be
   switched to opt-in via ``@`` operator.
-  Read more at :ref:`contributing-code-conventions-deprecations`;
+  Read more at :ref:`contributing-code-conventions-deprecations`.
 
 Naming Conventions
 ------------------

cookbook/bundles/best_practices.rst

@@ -113,22 +113,23 @@ them under the ``cache/`` or ``log/`` directory of the host application. Tools
 can generate files in the bundle directory structure, but only if the generated
 files are going to be part of the repository.
 
-The following classes and files have specific emplacements:
-
-===============================  =============================
-Type                             Directory
-===============================  =============================
-Commands                         ``Command/``
-Controllers                      ``Controller/``
-Service Container Extensions     ``DependencyInjection/``
-Event Listeners                  ``EventListener/``
-Model classes [1]                ``Model/``
-Configuration                    ``Resources/config/``
-Web Resources (CSS, JS, images)  ``Resources/public/``
-Translation files                ``Resources/translations/``
-Templates                        ``Resources/views/``
-Unit and Functional Tests        ``Tests/``
-===============================  =============================
+The following classes and files have specific emplacements (some are mandatory
+and others are just conventions followed by most developers):
+
+===============================  =============================  ================
+Type                             Directory                      Mandatory?
+===============================  =============================  ================
+Commands                         ``Command/``                   Yes
+Controllers                      ``Controller/``                No
+Service Container Extensions     ``DependencyInjection/``       Yes
+Event Listeners                  ``EventListener/``             No
+Model classes [1]                ``Model/``                     No
+Configuration                    ``Resources/config/``          No
+Web Resources (CSS, JS, images)  ``Resources/public/``          Yes
+Translation files                ``Resources/translations/``    Yes
+Templates                        ``Resources/views/``           Yes
+Unit and Functional Tests        ``Tests/``                     No
+===============================  =============================  ================
 
 [1] See :doc:`/cookbook/doctrine/mapping_model_classes` for how to handle the
 mapping with a compiler pass.

cookbook/event_dispatcher/event_listener.rst

@@ -65,7 +65,7 @@ The most common way to listen to an event is to register an **event listener**::
     Each event receives a slightly different type of ``$event`` object. For
     the ``kernel.exception`` event, it is :class:`Symfony\\Component\\HttpKernel\\Event\\GetResponseForExceptionEvent`.
     To see what type of object each event listener receives, see :class:`Symfony\\Component\\HttpKernel\\KernelEvents`
-    or the documentation about the specific even you're listening to.
+    or the documentation about the specific event you're listening to.
 
 Now that the class is created, you just need to register it as a service and
 notify Symfony that it is a "listener" on the ``kernel.exception`` event by