Updated contributor branch references - 2.0 no longer maintained

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.