From b93b1a791900ed8823ef0a566a9d1168e73bf802 Mon Sep 17 00:00:00 2001 From: Wouter de Jong Date: Tue, 17 Nov 2020 10:18:36 +0100 Subject: [PATCH] Prepare for 3.4 end of life --- README.markdown | 6 ++-- .../cache/adapters/filesystem_adapter.rst | 8 ++--- .../adapters/pdo_doctrine_dbal_adapter.rst | 2 +- .../cache/adapters/php_files_adapter.rst | 2 +- components/cache/cache_invalidation.rst | 2 +- contributing/code/pull_requests.rst | 32 +++++++++---------- contributing/community/releases.rst | 18 +++++------ contributing/documentation/overview.rst | 14 ++++---- 8 files changed, 41 insertions(+), 43 deletions(-) diff --git a/README.markdown b/README.markdown index 8923f022322..b993cd45ed4 100644 --- a/README.markdown +++ b/README.markdown @@ -11,9 +11,9 @@ Symfony documentation, please read [Contributing to the Documentation](https://symfony.com/doc/current/contributing/documentation/overview.html) > **Note** -> All pull requests must be based off of the **3.4** branch, -> unless you're documenting a feature that was introduced *after* Symfony 3.4 -> (e.g. in Symfony 4.4), **not** the master or older branches. +> All pull requests must be based off of the **4.4** branch, +> unless you're documenting a feature that was introduced *after* Symfony 4.4 +> (e.g. in Symfony 5.2), **not** the ``5.x`` or older branches. SymfonyCloud ------------ diff --git a/components/cache/adapters/filesystem_adapter.rst b/components/cache/adapters/filesystem_adapter.rst index c4db3a7fb76..772a6d7b6a9 100644 --- a/components/cache/adapters/filesystem_adapter.rst +++ b/components/cache/adapters/filesystem_adapter.rst @@ -50,11 +50,9 @@ and cache root path as constructor parameters:: .. note:: - Since Symfony 3.4, this adapter implements - :class:`Symfony\\Component\\Cache\\PruneableInterface`, enabling manual - :ref:`pruning of expired cache items ` by - calling its ``prune()`` method. - + This adapter implements :class:`Symfony\\Component\\Cache\\PruneableInterface`, + enabling manual :ref:`pruning of expired cache items ` + by calling its ``prune()`` method. .. _filesystem-tag-aware-adapter: diff --git a/components/cache/adapters/pdo_doctrine_dbal_adapter.rst b/components/cache/adapters/pdo_doctrine_dbal_adapter.rst index 841071dc586..b840da76de7 100644 --- a/components/cache/adapters/pdo_doctrine_dbal_adapter.rst +++ b/components/cache/adapters/pdo_doctrine_dbal_adapter.rst @@ -44,7 +44,7 @@ your code. .. note:: - Since Symfony 3.4, this adapter implements :class:`Symfony\\Component\\Cache\\PruneableInterface`, + This adapter implements :class:`Symfony\\Component\\Cache\\PruneableInterface`, allowing for manual :ref:`pruning of expired cache entries ` by calling its ``prune()`` method. diff --git a/components/cache/adapters/php_files_adapter.rst b/components/cache/adapters/php_files_adapter.rst index 5bec5715801..fcb5bcfffd1 100644 --- a/components/cache/adapters/php_files_adapter.rst +++ b/components/cache/adapters/php_files_adapter.rst @@ -63,7 +63,7 @@ directory path as constructor arguments:: .. note:: - Since Symfony 3.4, this adapter implements :class:`Symfony\\Component\\Cache\\PruneableInterface`, + This adapter implements :class:`Symfony\\Component\\Cache\\PruneableInterface`, allowing for manual :ref:`pruning of expired cache entries ` by calling its ``prune()`` method. diff --git a/components/cache/cache_invalidation.rst b/components/cache/cache_invalidation.rst index bef2c29b0b7..d7e44031d90 100644 --- a/components/cache/cache_invalidation.rst +++ b/components/cache/cache_invalidation.rst @@ -87,7 +87,7 @@ your fronts and have very fast invalidation checks:: .. note:: - Since Symfony 3.4, :class:`Symfony\\Component\\Cache\\Adapter\\TagAwareAdapter` + :class:`Symfony\\Component\\Cache\\Adapter\\TagAwareAdapter` implements :class:`Symfony\\Component\\Cache\\PruneableInterface`, enabling manual :ref:`pruning of expired cache entries ` by diff --git a/contributing/code/pull_requests.rst b/contributing/code/pull_requests.rst index 15c2f6a4484..f76e778763f 100644 --- a/contributing/code/pull_requests.rst +++ b/contributing/code/pull_requests.rst @@ -124,7 +124,7 @@ Choose the right Branch Before working on a PR, you must determine on which branch you need to work: -* ``3.4``, if you are fixing a bug for an existing feature or want to make a +* ``4.4``, 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); @@ -132,16 +132,16 @@ work: * ``5.x``, if you are adding a new feature. The only exception is when a new :doc:`major Symfony version ` - (4.0, 5.0, etc.) comes out every two years. Because of the + (5.0, 6.0, etc.) comes out every two years. Because of the :ref:`special development process ` of those versions, - you need to use the previous minor version for the features (e.g. use ``3.4`` - instead of ``4.0``, use ``4.4`` instead of ``5.0``, etc.) + you need to use the previous minor version for the features (e.g. use ``4.4`` + instead of ``5.0``, use ``5.4`` instead of ``6.0``, etc.) .. 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 PR - for the ``3.4`` branch, the PR will also be applied by the core team on + for the ``4.4`` branch, the PR will also be applied by the core team on the ``5.x`` branch. Create a Topic Branch @@ -154,18 +154,18 @@ topic branch: $ git checkout -b BRANCH_NAME 5.x -Or, if you want to provide a bug fix for the ``3.4`` branch, first track the remote -``3.4`` branch locally: +Or, if you want to provide a bug fix for the ``4.4`` branch, first track the remote +``4.4`` branch locally: .. code-block:: terminal - $ git checkout --track origin/3.4 + $ git checkout --track origin/4.4 -Then create a new branch off the ``3.4`` branch to work on the bug fix: +Then create a new branch off the ``4.4`` branch to work on the bug fix: .. code-block:: terminal - $ git checkout -b BRANCH_NAME 3.4 + $ git checkout -b BRANCH_NAME 4.4 .. tip:: @@ -193,8 +193,8 @@ want to debug are installed by running ``composer install`` inside it. .. tip:: - If symlinks to your local Symfony fork cannot be resolved inside your project due to - your dev environment (for instance when using Vagrant where only the current project + If symlinks to your local Symfony fork cannot be resolved inside your project due to + your dev environment (for instance when using Vagrant where only the current project directory is mounted), you can alternatively use the ``--copy`` option. When finishing testing your Symfony code into your project, you can use the ``--rollback`` option to make your project back to its original dependencies. @@ -285,7 +285,7 @@ while to finish your changes): .. tip:: - Replace ``5.x`` with the branch you selected previously (e.g. ``3.4``) + Replace ``5.x`` with the branch you selected previously (e.g. ``4.4``) if you are working on a bug fix. When doing the ``rebase`` command, you might have to fix merge conflicts. @@ -312,8 +312,8 @@ You can now make a pull request on the ``symfony/symfony`` GitHub repository. .. tip:: - Take care to point your pull request towards ``symfony:3.4`` if you want - the core team to pull a bug fix based on the ``3.4`` branch. + Take care to point your pull request towards ``symfony:4.4`` if you want + the core team to pull a bug fix based on the ``4.4`` branch. To ease the core team work, always include the modified components in your pull request message, like in: @@ -403,7 +403,7 @@ Rework your Pull Request Based on the feedback on the pull request, you might need to rework your PR. Before re-submitting the PR, rebase with ``upstream/5.x`` or -``upstream/3.4``, don't merge; and force the push to the origin: +``upstream/4.4``, don't merge; and force the push to the origin: .. code-block:: terminal diff --git a/contributing/community/releases.rst b/contributing/community/releases.rst index fa8471717f2..80d5033accd 100644 --- a/contributing/community/releases.rst +++ b/contributing/community/releases.rst @@ -7,7 +7,7 @@ release and maintain its different versions. Symfony releases follow the `semantic versioning`_ strategy and they are published through a *time-based model*: -* A new **Symfony patch version** (e.g. 3.4.41, 4.4.9) comes out roughly every +* A new **Symfony patch version** (e.g. 4.4.12, 5.1.9) comes out roughly every month. It only contains bug fixes, so you can safely upgrade your applications; * A new **Symfony minor version** (e.g. 4.4, 5.0, 5.1) comes out every *six months*: one in *May* and one in *November*. It contains bug fixes and new features, but @@ -53,7 +53,7 @@ Maintenance Starting from the Symfony 3.x branch, the number of minor versions is limited to five per branch (X.0, X.1, X.2, X.3 and X.4). The last minor version of a branch -(e.g. 3.4, 4.4, 5.4) is considered a **long-term support version** and the other +(e.g. 4.4, 5.4) is considered a **long-term support version** and the other ones are considered **standard versions**: ======================= ===================== ================================ @@ -87,17 +87,17 @@ learn more about how deprecations are handled in Symfony. .. _major-version-development: This deprecation policy also requires a custom development process for major -versions (4.0, 5.0, 6.0, etc.) In those cases, Symfony develops at the same time -two versions: the new major one (e.g. 4.0) and the latest version of the -previous branch (e.g. 3.4). +versions (5.0, 6.0, etc.) In those cases, Symfony develops at the same time +two versions: the new major one (e.g. 5.0) and the latest version of the +previous branch (e.g. 4.4). Both versions have the same new features, but they differ in the deprecated -features. The oldest version (3.4 in this example) contains all the deprecated -features whereas the new version (4.0 in this example) removes all of them. +features. The oldest version (4.4 in this example) contains all the deprecated +features whereas the new version (5.0 in this example) removes all of them. -This allows you to upgrade your projects to the latest minor version (e.g. 3.4), +This allows you to upgrade your projects to the latest minor version (e.g. 4.4), see all the deprecation messages and fix them. Once you have fixed all those -deprecations, you can upgrade to the new major version (e.g. 4.0) without +deprecations, you can upgrade to the new major version (e.g. 5.0) without effort, because it contains the same features (the only difference are the deprecated features, which your project no longer uses). diff --git a/contributing/documentation/overview.rst b/contributing/documentation/overview.rst index fc6a2c4e5e5..f7d1e4e8a03 100644 --- a/contributing/documentation/overview.rst +++ b/contributing/documentation/overview.rst @@ -112,14 +112,14 @@ memorable name for the new branch (if you are fixing a reported issue, use .. code-block:: terminal - $ git checkout -b improve_install_article upstream/3.4 + $ git checkout -b improve_install_article upstream/4.4 In this example, the name of the branch is ``improve_install_article`` and the -``upstream/3.4`` value tells Git to create this branch based on the ``3.4`` +``upstream/4.4`` value tells Git to create this branch based on the ``4.4`` 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 ``3.4`` branch. If you are instead documenting a +the error. Nowadays this is the ``4.4`` 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. @@ -155,7 +155,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 ``3.4``, which is the branch that you selected +the **base** branch should be the ``4.4``, 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_article``, which is the name of the branch you created and where you made your changes. @@ -205,7 +205,7 @@ contribution to the Symfony docs: # create a new branch based on the oldest maintained version $ cd projects/symfony-docs/ $ git fetch upstream - $ git checkout -b my_changes upstream/3.4 + $ git checkout -b my_changes upstream/4.4 # ... do your changes @@ -303,8 +303,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 3.4, -your changes should always be based on the ``3.4`` branch. Documentation managers +Unless you're documenting a feature that was introduced after Symfony 4.4, +your changes should always be based on the ``4.4`` branch. Documentation managers will use the necessary Git-magic to also apply your changes to all the active branches of the documentation.