Merge branch '2.4'

Conflicts:
	components/stopwatch.rst

components/routing/hostname_pattern.rst

@@ -173,25 +173,27 @@ instance, if you want to match both ``m.example.com`` and
 
         return $collection;
 
-.. tip::
-
-    Make sure you also include a default option for the ``subdomain``
-    placeholder, otherwise you need to include the subdomains value each time
-    you generate the route.
-
 .. sidebar:: Using Service Parameters
 
     You can also use service parameters if you do not want to hardcode the
     hostname:
 
+    .. tip::
+
+       Make sure you also include a default option for the ``subdomain``
+       placeholder, otherwise you need to include the subdomains value each time
+       you generate the route.
+
     .. configuration-block::
 
         .. code-block:: yaml
 
             mobile_homepage:
                 path:     /
                 host:     "m.{domain}"
-                defaults: { _controller: AcmeDemoBundle:Main:mobileHomepage }
+                defaults:
+                    _controller: AcmeDemoBundle:Main:mobileHomepage
+                    domain: "%domain%"
                 requirements:
                     domain: "%domain%"
 
@@ -209,6 +211,7 @@ instance, if you want to match both ``m.example.com`` and
 
                 <route id="mobile_homepage" path="/" host="m.example.com">
                     <default key="_controller">AcmeDemoBundle:Main:mobileHomepage</default>
+                    <default key="domain">%domain%</requirement>
                     <requirement key="domain">%domain%</requirement>
                 </route>
 
@@ -225,6 +228,7 @@ instance, if you want to match both ``m.example.com`` and
             $collection = new RouteCollection();
             $collection->add('mobile_homepage', new Route('/', array(
                 '_controller' => 'AcmeDemoBundle:Main:mobileHomepage',
+                'domain' => '%domain%',
             ), array(
                 'domain' => '%domain%',
             ), array(), 'm.{domain}'));

components/stopwatch.rst

@@ -34,12 +34,13 @@ microtime by yourself. Instead, use the simple
 .. versionadded:: 2.5
     The ``getEvent()`` method was introduced in Symfony 2.5
 
-The :class:`Symfony\\Component\\Stopwatch\StopwatchEvent` object can be retrieved from the 
-:method:`Symfony\\Component\\Stopwatch\\Stopwatch::start`, 
+The :class:`Symfony\\Component\\Stopwatch\StopwatchEvent` object can be retrieved
+from the  :method:`Symfony\\Component\\Stopwatch\\Stopwatch::start`, 
 :method:`Symfony\\Component\\Stopwatch\\Stopwatch::stop`, 
 :method:`Symfony\\Component\\Stopwatch\\Stopwatch::lap` and 
 :method:`Symfony\\Component\\Stopwatch\\Stopwatch::getEvent` methods. 
-The latter should be used when you need to retrieve the duration of an event while it is still running.
+The latter should be used when you need to retrieve the duration of an event
+while it is still running.
 
 You can also provide a category name to an event::
 

contributing/community/releases.rst

@@ -4,8 +4,15 @@ The Release Process
 This document explains the Symfony release process (Symfony being the code
 hosted on the main ``symfony/symfony`` `Git repository`_).
 
-Symfony manages its releases through a *time-based model*; a new Symfony
-release comes out every *six months*: one in *May* and one in *November*.
+Symfony manages its releases through a *time-based model*; a new Symfony minor
+version comes out every *six months*: one in *May* and one in *November*.
+
+.. tip::
+
+    The meaning of "minor" comes from the `Semantic Versioning`_ strategy.
+
+Each minor version sticks to the same very well-defined process where we start
+with a development period, followed by a maintenance period.
 
 .. note::
 
@@ -18,7 +25,7 @@ release comes out every *six months*: one in *May* and one in *November*.
 Development
 -----------
 
-The six-months period is divided into two phases:
+The first six-month period is divided into two phases:
 
 * *Development*: *Four months* to add new features and to enhance existing
   ones;
@@ -36,8 +43,8 @@ final release.
 Maintenance
 -----------
 
-Each Symfony version is maintained for a fixed period of time, depending on
-the type of the release. We have two maintenance periods:
+Each Symfony minor version is maintained for a fixed period of time, depending
+on the type of the release. We have two maintenance periods:
 
 * *Bug fixes and security fixes*: During this period, all issues can be fixed.
   The end of this period is referenced as being the *end of maintenance* of a
@@ -47,17 +54,17 @@ the type of the release. We have two maintenance periods:
   be fixed. The end of this period is referenced as being the *end of
   life* of a release.
 
-Standard Releases
+Standard Versions
 ~~~~~~~~~~~~~~~~~
 
-A standard release is maintained for an *eight month* period for bug fixes,
-and for a *fourteen month* period for security issue fixes.
+A standard minor version is maintained for an *eight month* period for bug
+fixes, and for a *fourteen month* period for security issue fixes.
 
-Long Term Support Releases
+Long Term Support Versions
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Every two years, a new Long Term Support Release (aka LTS release) is
-published. Each LTS release is supported for a *three year* period for bug
+Every two years, a new Long Term Support Version (aka LTS version) is
+published. Each LTS version is supported for a *three year* period for bug
 fixes, and for a *four year* period for security issue fixes.
 
 .. note::
@@ -109,17 +116,26 @@ This results in very predictable dates and maintenance periods:
     use the online `timeline calculator`_. You can also get all data as a JSON
     string via a URL like `http://symfony.com/roadmap.json?version=2.x`.
 
+.. tip::
+
+    Whenever an important event related to Symfony versions happens (a version
+    reaches end of maintenance or a new patch version is released for
+    instance), you can automatically receive an email notification if you
+    subscribed on the `roadmap notification`_ page.
+
 Backward Compatibility
 ----------------------
 
-After the release of Symfony 2.3, backward compatibility will be kept at all
-cost. If it is not possible, the feature, the enhancement, or the bug fix will
-be scheduled for the next major version: Symfony 3.0.
+Our `Backwards Compatibility Promise`_ is very strict and allows developers to
+upgrade with confidence from one minor version of Symfony to the next one.
+
+Whenever keeping backward compatibility is not possible, the feature, the
+enhancement, or the bug fix will be scheduled for the next major version.
 
 .. note::
 
-    The work on Symfony 3.0 will start whenever enough major features breaking
-    backward compatibility are waiting on the todo-list.
+    The work on a new major version of Symfony starts whenever enough major
+    features breaking backward compatibility are waiting on the todo-list.
 
 Deprecations
 ------------
@@ -154,11 +170,12 @@ for the next cycle.
 
 The dual maintenance mode was adopted to make every Symfony user happy. Fast
 movers, who want to work with the latest and the greatest, use the standard
-releases: a new version is published every six months, and there is a two
-months period to upgrade. Companies wanting more stability use the LTS
-releases: a new version is published every two years and there is a year to
-upgrade.
+version: a new version is published every six months, and there is a two months
+period to upgrade. Companies wanting more stability use the LTS versions: a new
+version is published every two years and there is a year to upgrade.
 
+.. _Semantic Versioning: http://semver.org/
 .. _Git repository: https://github.com/symfony/symfony
 .. _SensioLabs:     http://sensiolabs.com/
-.. _`timeline calculator`: http://symfony.com/roadmap
+.. _roadmap notification: http://symfony.com/roadmap
+.. _timeline calculator: http://symfony.com/roadmap

cookbook/doctrine/file_uploads.rst

@@ -410,6 +410,14 @@ Next, refactor the ``Document`` class to take advantage of these callbacks::
         }
     }
 
+.. caution::
+
+   If changes to your entity are handled by a Doctrine event listener or event 
+   subscriber, the ``preUpdate()`` callback must notify Doctrine about the changes 
+   being done.
+   For full reference on preUpdate event restrictions, see `preUpdate`_ in the 
+   Doctrine Events documentation.
+
 The class now does everything you need: it generates a unique filename before
 persisting, moves the file after persisting, and removes the file if the
 entity is ever deleted.
@@ -546,3 +554,5 @@ You'll notice in this case that you need to do a little bit more work in
 order to remove the file. Before it's removed, you must store the file path
 (since it depends on the id). Then, once the object has been fully removed
 from the database, you can safely delete the file (in ``PostRemove``).
+
+.. _`preUpdate`: http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/events.html#preupdate