Fix Symfony versions when needed

README.markdown

@@ -26,8 +26,8 @@ Contributing
 We love contributors! For more information on how you can contribute, please read
 the [Symfony Docs Contributing Guide](https://symfony.com/doc/current/contributing/documentation/overview.html).
 
-**Important**: use `4.4` branch as the base of your pull requests, unless you are
-documenting a feature that was introduced *after* Symfony 4.4 (e.g. in Symfony 5.4).
+**Important**: use `5.4` branch as the base of your pull requests, unless you are
+documenting a feature that was introduced *after* Symfony 5.4 (e.g. in Symfony 6.2).
 
 Build Documentation Locally
 ---------------------------

contributing/code/pull_requests.rst

@@ -132,20 +132,20 @@ work:
   branch (you can find them on the `Symfony releases page`_). E.g. if you
   found a bug introduced in ``v5.1.10``, you need to work on ``5.4``.
 
-* ``6.2``, if you are adding a new feature.
+* ``6.3``, if you are adding a new feature.
 
   The only exception is when a new :doc:`major Symfony version </contributing/community/releases>`
   (5.0, 6.0, etc.) comes out every two years. Because of the
   :ref:`special development process <major-version-development>` of those versions,
-  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.)
+  you need to use the previous minor version for the features (e.g. use ``5.4``
+  instead of ``6.0``, use ``6.4`` instead of ``7.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 ``4.4`` branch, the PR will also be applied by the core team on
-    the ``5.x`` and ``6.x`` branches.
+    for the ``5.4`` branch, the PR will also be applied by the core team on
+    all the ``6.x`` branches that are still maintained.
 
 Create a Topic Branch
 ~~~~~~~~~~~~~~~~~~~~~
@@ -157,18 +157,18 @@ topic branch:
 
     $ git checkout -b BRANCH_NAME 5.x
 
-Or, if you want to provide a bug fix for the ``4.4`` branch, first track the remote
-``4.4`` branch locally:
+Or, if you want to provide a bug fix for the ``5.4`` branch, first track the remote
+``5.4`` branch locally:
 
 .. code-block:: terminal
 
-    $ git checkout --track origin/4.4
+    $ git checkout --track origin/5.4
 
-Then create a new branch off the ``4.4`` branch to work on the bug fix:
+Then create a new branch off the ``5.4`` branch to work on the bug fix:
 
 .. code-block:: terminal
 
-    $ git checkout -b BRANCH_NAME 4.4
+    $ git checkout -b BRANCH_NAME 5.4
 
 .. tip::
 
@@ -284,15 +284,15 @@ while to finish your changes):
 
 .. code-block:: terminal
 
-    $ git checkout 5.x
+    $ git checkout 6.x
     $ git fetch upstream
-    $ git merge upstream/5.x
+    $ git merge upstream/6.x
     $ git checkout BRANCH_NAME
-    $ git rebase 5.x
+    $ git rebase 6.x
 
 .. tip::
 
-    Replace ``5.x`` with the branch you selected previously (e.g. ``4.4``)
+    Replace ``6.x`` with the branch you selected previously (e.g. ``5.4``)
     if you are working on a bug fix.
 
 When doing the ``rebase`` command, you might have to fix merge conflicts.
@@ -319,8 +319,8 @@ You can now make a pull request on the ``symfony/symfony`` GitHub repository.
 
 .. tip::
 
-    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.
+    Take care to point your pull request towards ``symfony:5.4`` if you want
+    the core team to pull a bug fix based on the ``5.4`` branch.
 
 To ease the core team work, always include the modified components in your
 pull request message, like in:
@@ -461,7 +461,7 @@ test scenarios run on each change:
 
     This job also runs relevant packages using a "flipped" test (indicated
     by a ``^`` suffix in the package name). These tests checkout the
-    previous major release (e.g. ``4.4`` for a pull requests on ``5.4``)
+    previous major release (e.g. ``5.4`` for a pull requests on ``6.3``)
     and run the tests with your branch as dependency.
 
     A failure in these flipped tests indicate a backwards compatibility
@@ -500,12 +500,12 @@ 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/4.4``, don't merge; and force the push to the origin:
+PR. Before re-submitting the PR, rebase with ``upstream/6.x`` or
+``upstream/5.4``, don't merge; and force the push to the origin:
 
 .. code-block:: terminal
 
-    $ git rebase -f upstream/5.x
+    $ git rebase -f upstream/6.x
     $ git push --force origin BRANCH_NAME
 
 .. note::

contributing/code/tests.rst

@@ -32,7 +32,7 @@ tests, such as Doctrine, Twig and Monolog. To do so,
 
     .. code-block:: terminal
 
-        $ COMPOSER_ROOT_VERSION=4.4.x-dev composer update
+        $ COMPOSER_ROOT_VERSION=5.4.x-dev composer update
 
 .. _running:
 

contributing/community/releases.rst

@@ -7,9 +7,9 @@ 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. 4.4.12, 5.1.9) comes out roughly every
+* A new **Symfony patch version** (e.g. 5.4.12, 6.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*:
+* A new **Symfony minor version** (e.g. 5.4, 6.0, 6.1) comes out every *six months*:
   one in *May* and one in *November*. It contains bug fixes and new features,
   can contain new deprecations but it doesn't include any breaking change,
   so you can safely upgrade your applications;
@@ -54,7 +54,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. 4.4, 5.4) is considered a **long-term support version** and the other
+(e.g. 5.4, 6.4) is considered a **long-term support version** and the other
 ones are considered **standard versions**:
 
 =======================  =====================  ================================
@@ -88,17 +88,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 (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).
+versions (6.0, 7.0, etc.) In those cases, Symfony develops at the same time
+two versions: the new major one (e.g. 6.0) and the latest version of the
+previous branch (e.g. 5.4).
 
 Both versions have the same new features, but they differ in the deprecated
-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.
+features. The oldest version (5.4 in this example) contains all the deprecated
+features whereas the new version (6.0 in this example) removes all of them.
 
-This allows you to upgrade your projects to the latest minor version (e.g. 4.4),
+This allows you to upgrade your projects to the latest minor version (e.g. 5.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. 5.0) without
+deprecations, you can upgrade to the new major version (e.g. 6.0) without
 effort, because it contains the same features (the only difference are the
 deprecated features, which your project no longer uses).