Updated contributor branch references - 2.0 no longer maintained

The current documentation refers throughout to making bugfix and
corrections against the 2.0 branch, however this is no longer
maintained. Updated with references to 2.1 to make this more
obvious to new contributors.

Author: acoulton

README.markdown

@@ -6,10 +6,10 @@ This documentation is rendered online at http://symfony.com/doc/current/
 Contributing
 ------------
 
->**Note** 
->Unless you're documenting a feature that's new to a specific version of Symfony 
->(e.g. Symfony 2.1), all pull requests must be based off of the **2.0** branch, 
->**not** the master or 2.1 branch.
+>**Note**
+>Unless you're documenting a feature that's new to a specific version of Symfony
+>(e.g. Symfony 2.2), all pull requests must be based off of the **2.1** branch,
+>**not** the master or 2.2 branch.
 
 We love contributors! For more information on how you can contribute to the
 Symfony documentation, please read 

contributing/code/bugs.rst

@@ -30,7 +30,7 @@ If your problem definitely looks like a bug, report it using the official bug
 
 * *(optional)* Attach a :doc:`patch <patches>`.
 
-.. _documentation: http://symfony.com/doc/2.0/
+.. _documentation: http://symfony.com/doc/current/
 .. _users mailing-list: http://groups.google.com/group/symfony-users
 .. _forum: http://forum.symfony-project.org/
 .. _IRC channel: irc://irc.freenode.net/symfony

contributing/code/patches.rst

@@ -107,13 +107,13 @@ Choose the right Branch
 Before working on a patch, you must determine on which branch you need to
 work. The branch should be based on the `master` branch if you want to add a
 new feature. But if you want to fix a bug, use the oldest but still maintained
-version of Symfony where the bug happens (like `2.0`).
+version of Symfony where the bug happens (like `2.1`).
 
 .. note::
 
     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.0` branch, the patch will also be applied by the core team on
+    for the `2.1` branch, the patch will also be applied by the core team on
     the `master` branch.
 
 Create a Topic Branch
@@ -126,18 +126,18 @@ topic branch:
 
     $ git checkout -b BRANCH_NAME master
 
-Or, if you want to provide a bugfix for the 2.0 branch, first track the remote
-`2.0` branch locally:
+Or, if you want to provide a bugfix for the 2.1 branch, first track the remote
+`2.1` branch locally:
 
 .. code-block:: bash
 
-    $ git checkout -t origin/2.0
+    $ git checkout -t origin/2.1
 
-Then create a new branch off the 2.0 branch to work on the bugfix:
+Then create a new branch off the 2.1 branch to work on the bugfix:
 
 .. code-block:: bash
 
-    $ git checkout -b BRANCH_NAME 2.0
+    $ git checkout -b BRANCH_NAME 2.1
 
 .. tip::
 
@@ -230,7 +230,7 @@ while to finish your changes):
 
 .. tip::
 
-    Replace `master` with `2.0` if you are working on a bugfix
+    Replace `master` with `2.1` if you are working on a bugfix
 
 When doing the ``rebase`` command, you might have to fix merge conflicts.
 ``git status`` will show you the *unmerged* files. Resolve all the conflicts,
@@ -365,7 +365,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.0``, don't merge; and force the push to the origin:
+``upstream/2.1``, don't merge; and force the push to the origin:
 
 .. code-block:: bash
 

contributing/documentation/overview.rst

@@ -30,17 +30,17 @@ multiple branches: ``2.0``, ``2.1``, ``2.2`` corresponding to the different
 versions of Symfony itself. The ``master`` branch holds the documentation
 for the development branch of the code.
 
-Unless you're documenting a feature that was introduced *after* Symfony 2.0
-(e.g. in Symfony 2.1), your changes should always be based on the 2.0 branch.
-To do this checkout the 2.0 branch before the next step:
+Unless you're documenting a feature that was introduced *after* Symfony 2.1
+(e.g. in Symfony 2.2), your changes should always be based on the 2.1 branch.
+To do this checkout the 2.1 branch before the next step:
 
 .. code-block:: bash
 
-    $ git checkout 2.0
+    $ git checkout 2.1
 
 .. tip::
 
-    Your base branch (e.g. 2.0) will become the "Applies to" in the :ref:`doc-contributing-pr-format`
+    Your base branch (e.g. 2.1) will become the "Applies to" in the :ref:`doc-contributing-pr-format`
     that you'll use later.
 
 Next, create a dedicated branch for your changes (for organization):
@@ -61,16 +61,16 @@ Following the example, the pull request will default to be between your
 .. image:: /images/docs-pull-request.png
    :align: center
 
-If you have made your changes based on the 2.0 branch then you need to change
-the base branch to be 2.0 on the preview page:
+If you have made your changes based on the 2.1 branch then you need to change
+the base branch to be 2.1 on the preview page:
 
 .. image:: /images/docs-pull-request-change-base.png
    :align: center
 
 .. note::
 
-  All changes made to a branch (e.g. 2.0) will be merged up to each "newer"
-  branch (e.g. 2.1, master, etc) for the next release on a weekly basis.
+  All changes made to a branch (e.g. 2.1) will be merged up to each "newer"
+  branch (e.g. 2.2, master, etc) for the next release on a weekly basis.
 
 GitHub covers the topic of `pull requests`_ in detail.