mirror of
https://github.com/symfony/symfony-docs.git
synced 2026-03-24 00:32:14 +01:00
Merge branch '2.2'
This commit is contained in:
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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::
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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 |
Reference in New Issue
Block a user