Skip to content

Commit 12cc8a2

Browse files
committed
Fix Symfony versions when needed
1 parent 8b8cf56 commit 12cc8a2

File tree

4 files changed

+33
-33
lines changed

4 files changed

+33
-33
lines changed

README.markdown

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -26,8 +26,8 @@ Contributing
2626
We love contributors! For more information on how you can contribute, please read
2727
the [Symfony Docs Contributing Guide](https://symfony.com/doc/current/contributing/documentation/overview.html).
2828

29-
**Important**: use `4.4` branch as the base of your pull requests, unless you are
30-
documenting a feature that was introduced *after* Symfony 4.4 (e.g. in Symfony 5.4).
29+
**Important**: use `5.4` branch as the base of your pull requests, unless you are
30+
documenting a feature that was introduced *after* Symfony 5.4 (e.g. in Symfony 6.2).
3131

3232
Build Documentation Locally
3333
---------------------------

contributing/code/pull_requests.rst

Lines changed: 20 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -132,20 +132,20 @@ work:
132132
branch (you can find them on the `Symfony releases page`_). E.g. if you
133133
found a bug introduced in ``v5.1.10``, you need to work on ``5.4``.
134134

135-
* ``6.2``, if you are adding a new feature.
135+
* ``6.3``, if you are adding a new feature.
136136

137137
The only exception is when a new :doc:`major Symfony version </contributing/community/releases>`
138138
(5.0, 6.0, etc.) comes out every two years. Because of the
139139
:ref:`special development process <major-version-development>` of those versions,
140-
you need to use the previous minor version for the features (e.g. use ``4.4``
141-
instead of ``5.0``, use ``5.4`` instead of ``6.0``, etc.)
140+
you need to use the previous minor version for the features (e.g. use ``5.4``
141+
instead of ``6.0``, use ``6.4`` instead of ``7.0``, etc.)
142142

143143
.. note::
144144

145145
All bug fixes merged into maintenance branches are also merged into more
146146
recent branches on a regular basis. For instance, if you submit a PR
147-
for the ``4.4`` branch, the PR will also be applied by the core team on
148-
the ``5.x`` and ``6.x`` branches.
147+
for the ``5.4`` branch, the PR will also be applied by the core team on
148+
all the ``6.x`` branches that are still maintained.
149149

150150
Create a Topic Branch
151151
~~~~~~~~~~~~~~~~~~~~~
@@ -157,18 +157,18 @@ topic branch:
157157
158158
$ git checkout -b BRANCH_NAME 5.x
159159
160-
Or, if you want to provide a bug fix for the ``4.4`` branch, first track the remote
161-
``4.4`` branch locally:
160+
Or, if you want to provide a bug fix for the ``5.4`` branch, first track the remote
161+
``5.4`` branch locally:
162162

163163
.. code-block:: terminal
164164
165-
$ git checkout --track origin/4.4
165+
$ git checkout --track origin/5.4
166166
167-
Then create a new branch off the ``4.4`` branch to work on the bug fix:
167+
Then create a new branch off the ``5.4`` branch to work on the bug fix:
168168

169169
.. code-block:: terminal
170170
171-
$ git checkout -b BRANCH_NAME 4.4
171+
$ git checkout -b BRANCH_NAME 5.4
172172
173173
.. tip::
174174

@@ -284,15 +284,15 @@ while to finish your changes):
284284

285285
.. code-block:: terminal
286286
287-
$ git checkout 5.x
287+
$ git checkout 6.x
288288
$ git fetch upstream
289-
$ git merge upstream/5.x
289+
$ git merge upstream/6.x
290290
$ git checkout BRANCH_NAME
291-
$ git rebase 5.x
291+
$ git rebase 6.x
292292
293293
.. tip::
294294

295-
Replace ``5.x`` with the branch you selected previously (e.g. ``4.4``)
295+
Replace ``6.x`` with the branch you selected previously (e.g. ``5.4``)
296296
if you are working on a bug fix.
297297

298298
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.
319319

320320
.. tip::
321321

322-
Take care to point your pull request towards ``symfony:4.4`` if you want
323-
the core team to pull a bug fix based on the ``4.4`` branch.
322+
Take care to point your pull request towards ``symfony:5.4`` if you want
323+
the core team to pull a bug fix based on the ``5.4`` branch.
324324

325325
To ease the core team work, always include the modified components in your
326326
pull request message, like in:
@@ -461,7 +461,7 @@ test scenarios run on each change:
461461

462462
This job also runs relevant packages using a "flipped" test (indicated
463463
by a ``^`` suffix in the package name). These tests checkout the
464-
previous major release (e.g. ``4.4`` for a pull requests on ``5.4``)
464+
previous major release (e.g. ``5.4`` for a pull requests on ``6.3``)
465465
and run the tests with your branch as dependency.
466466

467467
A failure in these flipped tests indicate a backwards compatibility
@@ -500,12 +500,12 @@ Rework your Pull Request
500500
~~~~~~~~~~~~~~~~~~~~~~~~
501501

502502
Based on the feedback on the pull request, you might need to rework your
503-
PR. Before re-submitting the PR, rebase with ``upstream/5.x`` or
504-
``upstream/4.4``, don't merge; and force the push to the origin:
503+
PR. Before re-submitting the PR, rebase with ``upstream/6.x`` or
504+
``upstream/5.4``, don't merge; and force the push to the origin:
505505

506506
.. code-block:: terminal
507507
508-
$ git rebase -f upstream/5.x
508+
$ git rebase -f upstream/6.x
509509
$ git push --force origin BRANCH_NAME
510510
511511
.. note::

contributing/code/tests.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -32,7 +32,7 @@ tests, such as Doctrine, Twig and Monolog. To do so,
3232

3333
.. code-block:: terminal
3434
35-
$ COMPOSER_ROOT_VERSION=4.4.x-dev composer update
35+
$ COMPOSER_ROOT_VERSION=5.4.x-dev composer update
3636
3737
.. _running:
3838

contributing/community/releases.rst

Lines changed: 10 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -7,9 +7,9 @@ release and maintain its different versions.
77
Symfony releases follow the `semantic versioning`_ strategy and they are
88
published through a *time-based model*:
99

10-
* A new **Symfony patch version** (e.g. 4.4.12, 5.1.9) comes out roughly every
10+
* A new **Symfony patch version** (e.g. 5.4.12, 6.1.9) comes out roughly every
1111
month. It only contains bug fixes, so you can safely upgrade your applications;
12-
* A new **Symfony minor version** (e.g. 4.4, 5.0, 5.1) comes out every *six months*:
12+
* A new **Symfony minor version** (e.g. 5.4, 6.0, 6.1) comes out every *six months*:
1313
one in *May* and one in *November*. It contains bug fixes and new features,
1414
can contain new deprecations but it doesn't include any breaking change,
1515
so you can safely upgrade your applications;
@@ -54,7 +54,7 @@ Maintenance
5454

5555
Starting from the Symfony 3.x branch, the number of minor versions is limited to
5656
five per branch (X.0, X.1, X.2, X.3 and X.4). The last minor version of a branch
57-
(e.g. 4.4, 5.4) is considered a **long-term support version** and the other
57+
(e.g. 5.4, 6.4) is considered a **long-term support version** and the other
5858
ones are considered **standard versions**:
5959

6060
======================= ===================== ================================
@@ -88,17 +88,17 @@ learn more about how deprecations are handled in Symfony.
8888
.. _major-version-development:
8989

9090
This deprecation policy also requires a custom development process for major
91-
versions (5.0, 6.0, etc.) In those cases, Symfony develops at the same time
92-
two versions: the new major one (e.g. 5.0) and the latest version of the
93-
previous branch (e.g. 4.4).
91+
versions (6.0, 7.0, etc.) In those cases, Symfony develops at the same time
92+
two versions: the new major one (e.g. 6.0) and the latest version of the
93+
previous branch (e.g. 5.4).
9494

9595
Both versions have the same new features, but they differ in the deprecated
96-
features. The oldest version (4.4 in this example) contains all the deprecated
97-
features whereas the new version (5.0 in this example) removes all of them.
96+
features. The oldest version (5.4 in this example) contains all the deprecated
97+
features whereas the new version (6.0 in this example) removes all of them.
9898

99-
This allows you to upgrade your projects to the latest minor version (e.g. 4.4),
99+
This allows you to upgrade your projects to the latest minor version (e.g. 5.4),
100100
see all the deprecation messages and fix them. Once you have fixed all those
101-
deprecations, you can upgrade to the new major version (e.g. 5.0) without
101+
deprecations, you can upgrade to the new major version (e.g. 6.0) without
102102
effort, because it contains the same features (the only difference are the
103103
deprecated features, which your project no longer uses).
104104

0 commit comments

Comments
 (0)