Merge branch '2.2'

This commit is contained in:
Ryan Weaver
2013-05-03 12:51:11 -06:00
7 changed files with 34 additions and 25 deletions

View File

@@ -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

View File

@@ -54,7 +54,7 @@ Simply passing a subject::
use Symfony\Component\EventDispatcher\GenericEvent;
$event = GenericEvent($subject);
$event = new GenericEvent($subject);
$dispatcher->dispatch('foo', $event);
class FooListener

View File

@@ -45,6 +45,9 @@ output. Alternatively, the :method:`Symfony\\Component\\Process\\Process::getInc
and :method:`Symfony\\Component\\Process\\Process::getIncrementalErrorOutput`
methods returns the new outputs since the last call.
Getting real-time Process Output
--------------------------------
When executing a long running command (like rsync-ing files to a remote
server), you can give feedback to the end user in real-time by passing an
anonymous function to the
@@ -63,7 +66,10 @@ anonymous function to the
.. versionadded:: 2.1
The non-blocking feature was added in 2.1.
Running Processes Asynchronously
--------------------------------
You can also start the subprocess and then let it run asynchronously, retrieving
output and the status in your main process whenever you need it. Use the
:method:`Symfony\\Component\\Process\\Process::start` method to start an asynchronous
@@ -96,6 +102,9 @@ are done doing other stuff::
}
});
Executing PHP Code in Isolation
-------------------------------
If you want to execute some PHP code in isolation, use the ``PhpProcess``
instead::

View File

@@ -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

View File

@@ -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

View File

@@ -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.

Binary file not shown.

Before

Width:  |  Height:  |  Size: 15 KiB

After

Width:  |  Height:  |  Size: 3.3 KiB