Merge branch '2.1'

* 2.1:
  fixed some markup issues
  Tweaks per @wouterj
  Fixed typo in documentation/overview
  Fixing typo thanks to @richardmiller
  [#1758] Minor tweaks - including fixing syntax errors around the image directive and describing the image
  added a new chapter about the Symfony release process
  Remove extra word
  Add missing words
  Try to fix a link
  Add missing apostrophe
  added missing letter
  fix minor typo

Author: fabpot

book/translation.rst

@@ -561,7 +561,7 @@ by defining a ``default_locale`` for the framework:
 The Locale and the URL
 ~~~~~~~~~~~~~~~~~~~~~~
 
-Since you can store the locale of the user is in the session, it may be tempting
+Since you can store the locale of the user in the session, it may be tempting
 to use the same URL to display a resource in many different languages based
 on the user's locale. For example, ``http://www.example.com/contact`` could
 show content in English for one user and French for another user. Unfortunately,

components/dependency_injection/compilation.rst

@@ -287,7 +287,7 @@ will then be called when the container is compiled::
 
 .. note::
 
-    Compiler passes are registered differently is you are using the full
+    Compiler passes are registered differently if you are using the full
     stack framework, see :doc:`/cookbook/service_container/compiler_passes`
     for more details.
 
@@ -408,7 +408,7 @@ but getting an up to date configuration whilst developing your application::
 This could be further improved by only recompiling the container in debug
 mode when changes have been made to its configuration rather than on every
 request. This can be done by caching the resource files used to configure
-the container in the way describe in ":doc:`/components/config/caching`"
+the container in the way described in ":doc:`/components/config/caching`"
 in the config component documentation.
 
 You do not need to work out which files to cache as the container builder

components/dependency_injection/workflow.rst

@@ -51,7 +51,7 @@ Bundle-level Configuration with Extensions
 
 By convention, each bundle contains an Extension class which is in the bundle's
 ``DependencyInjection`` directory. These are registered with the ``ContainerBuilder``
-when the kernel is booted. When the ``ContainerBuilder`` is :doc:`/compiled<components/dependency-injection/compilation>`,
+when the kernel is booted. When the ``ContainerBuilder`` is :doc:`compiled</components/dependency-injection/compilation>`,
 the application-level configuration relevant to the bundle's extension is
 passed to the Extension which also usually loads its own config file(s), typically from the bundle's
 ``Resources/config`` directory. The application-level config is usually processed
@@ -63,7 +63,7 @@ Compiler passes to allow Interaction between Bundles
 
 :ref:`Compiler passes<components-dependency-injection-compiler-passes>` are
 used to allow interaction between different bundles as they cannot affect
-each others configuration in the extension classes. One of the main uses is
+each other's configuration in the extension classes. One of the main uses is
 to process tagged services, allowing bundles to register services to picked
 up by other bundles, such as Monolog loggers, Twig extensions and Data Collectors
 for the Web Profiler. Compiler passes are usually placed in the bundle's
@@ -74,5 +74,5 @@ Compilation and Caching
 
 After the compilation process has loaded the services from the configuration,
 extensions and the compiler passes, it is dumped so that the cache can be used
-next time. The dumped version is then used during subsequent request as it
+next time. The dumped version is then used during subsequent requests as it
 is more efficient.

contributing/community/index.rst

@@ -4,5 +4,6 @@ Community
 .. toctree::
     :maxdepth: 2
 
+    releases
     irc
     other

contributing/community/releases.rst

@@ -0,0 +1,117 @@
+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*.
+
+.. note::
+
+    This release process has been adopted as of Symfony 2.2, and all the
+    "rules" explained in this document must be strictly followed as of Symfony
+    2.4.
+
+Development
+-----------
+
+The six-months period is divided into two phases:
+
+* *Development*: *Four months* to add new features and to enhance existing
+  ones;
+
+* *Stabilisation*: *Two months* to fix bugs, prepare the release, and wait
+  for the whole Symfony ecosystem (third-party libraries, bundles, and
+  projects using Symfony) to catch up.
+
+During the development phase, any new feature can be reverted if it won't be
+finished in time or if it won't be stable enough to be included in the current
+final release.
+
+Maintenance
+-----------
+
+Each Symfony version is maintained for a fixed period of time, depending on
+the type of the release.
+
+Standard Releases
+~~~~~~~~~~~~~~~~~
+
+A standard release is maintained for an *eight month* period.
+
+Long Term Support Releases
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Every two years, a new Long Term Support Release (aka LTS release) is
+published. Each LTS release is supported for a *three year* period.
+
+.. note::
+
+    Paid support after the three year support provided by the community can
+    also be bought from `SensioLabs`_.
+
+Schedule
+--------
+
+Below is the schedule for the first few versions that use this release model:
+
+.. image:: /images/release-process.jpg
+   :align: center
+
+* **Yellow** represents the Development phase
+* **Blue** represents the Stabilisation phase
+* **Green** represents the Maintenance period
+
+This results in very predictable dates and maintenance periods.
+
+* *(special)* Symfony 2.2 will be released at the end of February 2013;
+* *(special)* Symfony 2.3 (the first LTS) will be released at the end of May
+   2013;
+* Symfony 2.4 will be released at the end of November 2013;
+* Symfony 2.5 will be released at the end of May 2014;
+* ...
+
+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.
+
+.. note::
+
+    The work on Symfony 3.0 will start whenever enough major features breaking
+    backward compatibility are waiting on the todo-list.
+
+Rationale
+---------
+
+This release process was adopted to give more *predictability* and
+*transparency*. It was discussed based on the following goals:
+
+* Shorten the release cycle (allow developers to benefit from the new
+  features faster);
+* Give more visibility to the developers using the framework and Open-Source
+  projects using Symfony;
+* Improve the experience of Symfony core contributors: everyone knows when a
+  feature might be available in Symfony;
+* Coordinate the Symfony timeline with popular PHP projects that work well
+  with Symfony and with projects using Symfony;
+* Give time to the Symfony ecosystem to catch up with the new versions
+  (bundle authors, documentation writers, translators, ...).
+
+The six month period was chosen as two releases fit in a year. It also allows
+for plenty of time to work on new features and it allows for non-ready
+features to be postponed to the next version without having to wait too long
+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.
+
+.. _Git repository: https://github.com/symfony/symfony
+.. _SensioLabs:     http://sensiolabs.com/

contributing/documentation/overview.rst

@@ -87,7 +87,7 @@ look and feel familiar, you should follow these rules:
   If we fold several lines: the description of the fold can be placed after the ``...``
   If we fold only part of a line: the description can be placed before the line;
 * If useful, a ``codeblock`` should begin with a comment containing the filename
-  of the file in the code block. Place a blank line after this comment,
+  of the file in the code block. Don't place a blank line after this comment,
   unless the next line is also a comment;
 * You should put a ``$`` in front of every bash line;
 * We prefer the ``::`` shorthand over ``.. code-block:: php`` to begin a PHP

contributing/map.rst.inc

@@ -17,5 +17,6 @@
 
 * **Community**
 
+  * :doc:`Release Process </contributing/community/releases>`
   * :doc:`IRC Meetings </contributing/community/irc>`
   * :doc:`Other Resources </contributing/community/other>`

cookbook/console/generating_urls.rst

@@ -35,6 +35,7 @@ via normal web requests, since those will override the defaults.
 
     .. code-block:: xml
 
+        <!-- app/config/parameters.xml -->
         <?xml version="1.0" encoding="UTF-8"?>
 
         <container xmlns="http://symfony.com/schema/dic/services"
@@ -59,8 +60,8 @@ To change it only in one command you can simply fetch the Request Context
 service and override its settings::
 
     // src/Acme/DemoBundle/Command/DemoCommand.php
-    // ...
 
+    // ...
     class DemoCommand extends ContainerAwareCommand
     {
         protected function execute(InputInterface $input, OutputInterface $output)

cookbook/form/form_collections.rst

@@ -17,7 +17,8 @@ that Task, right inside the same form.
     of this tutorial that really care about "persistence".
 
     If you *are* using Doctrine, you'll need to add the Doctrine metadata,
-    including the ``ManyToMany`` on the Task's ``tags`` property.
+    including the ``ManyToMany`` association mapping definition on the Task's
+    ``tags`` property.
 
 Let's start there: suppose that each ``Task`` belongs to multiple ``Tags``
 objects. Start by creating a simple ``Task`` class::