Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reflect the EOM of Symfony 2.3 #6626

Merged
merged 1 commit into from
Jun 6, 2016
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions README.markdown
Original file line number Diff line number Diff line change
Expand Up @@ -7,8 +7,8 @@ Contributing
------------

>**Note**
>Unless you're documenting a feature that was introduced *after* Symfony 2.3
>(e.g. in Symfony 2.4), all pull requests must be based off of the **2.3** branch,
>Unless you're documenting a feature that was introduced *after* Symfony 2.7
>(e.g. in Symfony 2.8), all pull requests must be based off of the **2.7** branch,
>**not** the master or older branches.

We love contributors! For more information on how you can contribute to the
Expand Down
14 changes: 7 additions & 7 deletions components/form/introduction.rst
Original file line number Diff line number Diff line change
Expand Up @@ -163,14 +163,14 @@ component offers a rich integration.

To use the integration, you'll need the ``TwigBridge``, which provides integration
between Twig and several Symfony components. If you're using Composer, you
could install the latest 2.3 version by adding the following ``require``
could install the latest 2.7 version by adding the following ``require``
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The installation instructions in this document should probably be rewritten, but that should be done in a different PR.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see #6639

line to your ``composer.json`` file:

.. code-block:: json

{
"require": {
"symfony/twig-bridge": "2.3.*"
"symfony/twig-bridge": "2.7.*"
}
}

Expand Down Expand Up @@ -246,15 +246,15 @@ via your own Twig extension.

To use the built-in integration, be sure that your project has Symfony's
Translation and :doc:`Config </components/config/introduction>` components
installed. If you're using Composer, you could get the latest 2.3 version
installed. If you're using Composer, you could get the latest 2.7 version
of each of these by adding the following to your ``composer.json`` file:

.. code-block:: json

{
"require": {
"symfony/translation": "2.3.*",
"symfony/config": "2.3.*"
"symfony/translation": "2.7.*",
"symfony/config": "2.7.*"
}
}

Expand Down Expand Up @@ -298,13 +298,13 @@ array or object) and pass it through your own validation system.

To use the integration with Symfony's Validator component, first make sure
it's installed in your application. If you're using Composer and want to
install the latest 2.3 version, add this to your ``composer.json``:
install the latest 2.7 version, add this to your ``composer.json``:

.. code-block:: json

{
"require": {
"symfony/validator": "2.3.*"
"symfony/validator": "2.7.*"
}
}

Expand Down
22 changes: 11 additions & 11 deletions contributing/code/patches.rst
Original file line number Diff line number Diff line change
Expand Up @@ -113,7 +113,7 @@ Choose the right Branch
Before working on a patch, you must determine on which branch you need to
work:

* ``2.3``, if you are fixing a bug for an existing feature or want to make a
* ``2.7``, if you are fixing a bug for an existing feature or want to make a
change that falls into the :doc:`list of acceptable changes in patch versions
</contributing/code/maintenance>` (you may have to choose a higher branch if
the feature you are fixing was introduced in a later version);
Expand All @@ -124,7 +124,7 @@ work:

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.3`` branch, the patch will also be applied by the core team on
for the ``2.7`` branch, the patch will also be applied by the core team on
the ``master`` branch.

Create a Topic Branch
Expand All @@ -137,18 +137,18 @@ topic branch:

$ git checkout -b BRANCH_NAME master

Or, if you want to provide a bugfix for the ``2.3`` branch, first track the remote
``2.3`` branch locally:
Or, if you want to provide a bugfix for the ``2.7`` branch, first track the remote
``2.7`` branch locally:

.. code-block:: bash

$ git checkout -t origin/2.3
$ git checkout -t origin/2.7

Then create a new branch off the ``2.3`` branch to work on the bugfix:
Then create a new branch off the ``2.7`` branch to work on the bugfix:

.. code-block:: bash

$ git checkout -b BRANCH_NAME 2.3
$ git checkout -b BRANCH_NAME 2.7

.. tip::

Expand Down Expand Up @@ -236,7 +236,7 @@ while to finish your changes):

.. tip::

Replace ``master`` with the branch you selected previously (e.g. ``2.3``)
Replace ``master`` with the branch you selected previously (e.g. ``2.7``)
if you are working on a bugfix

When doing the ``rebase`` command, you might have to fix merge conflicts.
Expand All @@ -263,8 +263,8 @@ You can now make a pull request on the ``symfony/symfony`` GitHub repository.

.. tip::

Take care to point your pull request towards ``symfony:2.3`` if you want
the core team to pull a bugfix based on the ``2.3`` branch.
Take care to point your pull request towards ``symfony:2.7`` if you want
the core team to pull a bugfix based on the ``2.7`` branch.

To ease the core team work, always include the modified components in your
pull request message, like in:
Expand Down Expand Up @@ -335,7 +335,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.3``, don't merge; and force the push to the origin:
``upstream/2.7``, don't merge; and force the push to the origin:

.. code-block:: bash

Expand Down
8 changes: 4 additions & 4 deletions contributing/documentation/format.rst
Original file line number Diff line number Diff line change
Expand Up @@ -177,8 +177,8 @@ Symfony, you should precede your description of the change with a

.. code-block:: rst

.. versionadded:: 2.3
The ``askHiddenResponse`` method was introduced in Symfony 2.3.
.. versionadded:: 2.7
The ``askHiddenResponse`` method was introduced in Symfony 2.7.

You can also ask a question and hide the response. This is particularly [...]

Expand All @@ -187,9 +187,9 @@ how the behavior has changed:

.. code-block:: rst

.. versionadded:: 2.3
.. versionadded:: 2.7
The ``include()`` function is a new Twig feature that's available in
Symfony 2.3. Prior, the ``{% include %}`` tag was used.
Symfony 2.7. Prior, the ``{% include %}`` tag was used.

Whenever a new minor version of Symfony is released (e.g. 2.4, 2.5, etc),
a new branch of the documentation is created from the ``master`` branch.
Expand Down
14 changes: 7 additions & 7 deletions contributing/documentation/overview.rst
Original file line number Diff line number Diff line change
Expand Up @@ -116,14 +116,14 @@ memorable name for the new branch (if you are fixing a reported issue, use

.. code-block:: bash

$ git checkout -b improve_install_chapter upstream/2.3
$ git checkout -b improve_install_chapter upstream/2.7

In this example, the name of the branch is ``improve_install_chapter`` and the
``upstream/2.3`` value tells Git to create this branch based on the ``2.3``
``upstream/2.7`` value tells Git to create this branch based on the ``2.7``
branch of the ``upstream`` remote, which is the original Symfony Docs repository.

Fixes should always be based on the **oldest maintained branch** which contains
the error. Nowadays this is the ``2.3`` branch. If you are instead documenting a
the error. Nowadays this is the ``2.7`` branch. If you are instead documenting a
new feature, switch to the first Symfony version that included it, e.g.
``upstream/3.1``. Not sure? That's ok! Just use the ``upstream/master`` branch.

Expand Down Expand Up @@ -159,7 +159,7 @@ changes should be applied:
:align: center

In this example, the **base fork** should be ``symfony/symfony-docs`` and
the **base** branch should be the ``2.3``, which is the branch that you selected
the **base** branch should be the ``2.7``, which is the branch that you selected
to base your changes on. The **head fork** should be your forked copy
of ``symfony-docs`` and the **compare** branch should be ``improve_install_chapter``,
which is the name of the branch you created and where you made your changes.
Expand Down Expand Up @@ -208,7 +208,7 @@ contribution to the Symfony docs:

# create a new branch based on the oldest maintained version
$ cd projects/symfony-docs/
$ git checkout -b my_changes upstream/2.3
$ git checkout -b my_changes upstream/2.7

# ... do your changes

Expand Down Expand Up @@ -265,8 +265,8 @@ into multiple branches, corresponding to the different versions of Symfony itsel
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.3,
your changes should always be based on the ``2.3`` branch. Documentation managers
Unless you're documenting a feature that was introduced after Symfony 2.7,
your changes should always be based on the ``2.7`` branch. Documentation managers
will use the necessary Git-magic to also apply your changes to all the active
branches of the documentation.

Expand Down
22 changes: 13 additions & 9 deletions cookbook/upgrade/bundles.rst
Original file line number Diff line number Diff line change
Expand Up @@ -20,9 +20,9 @@ Most third-party bundles define their Symfony dependencies using the ``~2.N`` or

{
"require": {
"symfony/framework-bundle": "~2.3",
"symfony/finder": "~2.3",
"symfony/validator": "~2.3"
"symfony/framework-bundle": "~2.7",
"symfony/finder": "~2.7",
"symfony/validator": "~2.7"
}
}

Expand All @@ -37,9 +37,9 @@ The above example can be updated to work with Symfony 3 as follows:

{
"require": {
"symfony/framework-bundle": "~2.3|~3.0",
"symfony/finder": "~2.3|~3.0",
"symfony/validator": "~2.3|~3.0"
"symfony/framework-bundle": "~2.7|~3.0",
"symfony/finder": "~2.7|~3.0",
"symfony/validator": "~2.7|~3.0"
}
}

Expand Down Expand Up @@ -143,11 +143,15 @@ following recommended configuration as the starting point of your own configurat
- php: 5.3.3
env: COMPOSER_FLAGS='--prefer-lowest --prefer-stable' SYMFONY_DEPRECATIONS_HELPER=weak
- php: 5.6
env: SYMFONY_VERSION='2.3.*'
env: SYMFONY_VERSION='2.7.*'
- php: 5.6
env: DEPENDENCIES='dev' SYMFONY_VERSION='2.8.*@dev'
env: SYMFONY_VERSION='2.8.*'
- php: 5.6
env: SYMFONY_VERSION='3.0.*@dev'
env: SYMFONY_VERSION='3.0.*'
- php: 5.6
env: SYMFONY_VERSION='3.1.*'
- php: 5.6
env: DEPENDENCES='dev' SYMFONY_VERSION='3.2.*@dev'

before_install:
- composer self-update
Expand Down
2 changes: 1 addition & 1 deletion cookbook/upgrade/major_version.rst
Original file line number Diff line number Diff line change
Expand Up @@ -93,7 +93,7 @@ done!
.. sidebar:: Using the Weak Deprecations Mode

Sometimes, you can't fix all deprecations (e.g. something was deprecated
in 2.6 and you still need to support 2.3). In these cases, you can still
in 2.8 and you still need to support 2.7). In these cases, you can still
use the bridge to fix as many deprecations as possible and then switch
to the weak test mode to make your tests pass again. You can do this by
using the ``SYMFONY_DEPRECATIONS_HELPER`` env variable:
Expand Down