diff --git a/README.markdown b/README.markdown index 92816a63702..8d01c3cdcb7 100644 --- a/README.markdown +++ b/README.markdown @@ -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 diff --git a/components/form/introduction.rst b/components/form/introduction.rst index ce8e888c7c5..87fe409ed0c 100644 --- a/components/form/introduction.rst +++ b/components/form/introduction.rst @@ -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`` line to your ``composer.json`` file: .. code-block:: json { "require": { - "symfony/twig-bridge": "2.3.*" + "symfony/twig-bridge": "2.7.*" } } @@ -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 -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.*" } } @@ -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.*" } } diff --git a/contributing/code/patches.rst b/contributing/code/patches.rst index 37ac7bf4c02..24b914d4a4d 100644 --- a/contributing/code/patches.rst +++ b/contributing/code/patches.rst @@ -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 ` (you may have to choose a higher branch if the feature you are fixing was introduced in a later version); @@ -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 @@ -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:: @@ -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. @@ -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: @@ -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 diff --git a/contributing/documentation/format.rst b/contributing/documentation/format.rst index aec7b9d5866..1850a06a380 100644 --- a/contributing/documentation/format.rst +++ b/contributing/documentation/format.rst @@ -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 [...] @@ -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. diff --git a/contributing/documentation/overview.rst b/contributing/documentation/overview.rst index 056fe937b1e..0f663dddd98 100644 --- a/contributing/documentation/overview.rst +++ b/contributing/documentation/overview.rst @@ -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. @@ -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. @@ -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 @@ -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. diff --git a/cookbook/upgrade/bundles.rst b/cookbook/upgrade/bundles.rst index 73956089108..68bd0d351f1 100644 --- a/cookbook/upgrade/bundles.rst +++ b/cookbook/upgrade/bundles.rst @@ -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" } } @@ -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" } } @@ -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 diff --git a/cookbook/upgrade/major_version.rst b/cookbook/upgrade/major_version.rst index 44747c12724..978dac1c3ae 100644 --- a/cookbook/upgrade/major_version.rst +++ b/cookbook/upgrade/major_version.rst @@ -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: