Merge branch '4.0' into 4.1

* 4.0:
  Fixed more occurrences of the wrong handler name
  bugfixes should be placed for the 2.8 branch

Author: javiereguiluz

README.markdown

@@ -7,8 +7,8 @@ Contributing
 ------------
 
 >**Note**
->Unless you're documenting a feature that was introduced *after* Symfony 2.7
->(e.g. in Symfony 2.8), all pull requests must be based off of the **2.7** branch,
+>Unless you're documenting a feature that was introduced *after* Symfony 2.8
+>(e.g. in Symfony 3.4), all pull requests must be based off of the **2.8** branch,
 >**not** the master or older branches.
 
 We love contributors! For more information on how you can contribute to the

contributing/code/patches.rst

@@ -16,12 +16,6 @@ software:
 * Git;
 * PHP version 5.5.9 or above.
 
-.. caution::
-
-    Before Symfony 2.7, the minimal PHP version was 5.3.3. Before Symfony 3.0,
-    minimal version was 5.3.9. Please keep this in mind, if you are working on a
-    bug fix for earlier versions of Symfony.
-
 Configure Git
 ~~~~~~~~~~~~~
 
@@ -112,7 +106,7 @@ Choose the right Branch
 Before working on a patch, you must determine on which branch you need to
 work:
 
-* ``2.7``, if you are fixing a bug for an existing feature or want to make a
+* ``2.8``, if you are fixing a bug for an existing feature or want to make a
   change that falls into the :doc:`list of acceptable changes in patch versions
   </contributing/code/maintenance>` (you may have to choose a higher branch if
   the feature you are fixing was introduced in a later version);
@@ -123,7 +117,7 @@ work:
 
     All bug fixes merged into maintenance branches are also merged into more
     recent branches on a regular basis. For instance, if you submit a patch
-    for the ``2.7`` branch, the patch will also be applied by the core team on
+    for the ``2.8`` branch, the patch will also be applied by the core team on
     the ``master`` branch.
 
 Create a Topic Branch
@@ -136,18 +130,18 @@ topic branch:
 
     $ git checkout -b BRANCH_NAME master
 
-Or, if you want to provide a bugfix for the ``2.7`` branch, first track the remote
-``2.7`` branch locally:
+Or, if you want to provide a bugfix for the ``2.8`` branch, first track the remote
+``2.8`` branch locally:
 
 .. code-block:: terminal
 
-    $ git checkout -t origin/2.7
+    $ git checkout -t origin/2.8
 
-Then create a new branch off the ``2.7`` branch to work on the bugfix:
+Then create a new branch off the ``2.8`` branch to work on the bugfix:
 
 .. code-block:: terminal
 
-    $ git checkout -b BRANCH_NAME 2.7
+    $ git checkout -b BRANCH_NAME 2.8
 
 .. tip::
 
@@ -251,7 +245,7 @@ while to finish your changes):
 
 .. tip::
 
-    Replace ``master`` with the branch you selected previously (e.g. ``2.7``)
+    Replace ``master`` with the branch you selected previously (e.g. ``2.8``)
     if you are working on a bugfix
 
 When doing the ``rebase`` command, you might have to fix merge conflicts.
@@ -278,8 +272,8 @@ You can now make a pull request on the ``symfony/symfony`` GitHub repository.
 
 .. tip::
 
-    Take care to point your pull request towards ``symfony:2.7`` if you want
-    the core team to pull a bugfix based on the ``2.7`` branch.
+    Take care to point your pull request towards ``symfony:2.8`` if you want
+    the core team to pull a bugfix based on the ``2.8`` branch.
 
 To ease the core team work, always include the modified components in your
 pull request message, like in:
@@ -350,7 +344,7 @@ Rework your Patch
 
 Based on the feedback on the pull request, you might need to rework your
 patch. Before re-submitting the patch, rebase with ``upstream/master`` or
-``upstream/2.7``, don't merge; and force the push to the origin:
+``upstream/2.8``, don't merge; and force the push to the origin:
 
 .. code-block:: terminal
 

logging/monolog_email.rst

@@ -17,7 +17,7 @@ it is broken down.
         # config/packages/prod/monolog.yaml
         monolog:
             handlers:
-                mail:
+                main:
                     type:         fingers_crossed
                     # 500 errors are logged at the critical level
                     action_level: critical
@@ -60,7 +60,7 @@ it is broken down.
                 <monolog:excluded-404>^/</monolog:excluded-404>
                 -->
                 <monolog:handler
-                    name="mail"
+                    name="main"
                     type="fingers_crossed"
                     action-level="critical"
                     handler="deduplicated"
@@ -96,7 +96,7 @@ it is broken down.
         // config/packages/prod/monolog.php
         $container->loadFromExtension('monolog', array(
             'handlers' => array(
-                'mail' => array(
+                'main' => array(
                     'type'         => 'fingers_crossed',
                     // 500 errors are logged at the critical level
                     'action_level' => 'critical',
@@ -125,7 +125,7 @@ it is broken down.
             ),
         ));
 
-The ``mail`` handler is a ``fingers_crossed`` handler which means that
+The ``main`` handler is a ``fingers_crossed`` handler which means that
 it is only triggered when the action level, in this case ``critical`` is reached.
 The ``critical`` level is only triggered for 5xx HTTP code errors. If this level
 is reached once, the ``fingers_crossed`` handler will log all messages

service_container.rst

@@ -697,7 +697,7 @@ By putting the ``bind`` key under ``_defaults``, you can specify the value of *a
 argument for *any* service defined in this file! You can bind arguments by name
 (e.g. ``$adminEmail``) or by type (e.g. ``Psr\Log\LoggerInterface``).
 
-The ``bind`` config can be also be applied to specific services or when loading many
+The ``bind`` config can also be applied to specific services or when loading many
 services at once (i.e. :ref:`service-psr4-loader`).
 
 Getting Container Parameters as a Service