Merge branch '4.4' into 5.4

javiereguiluz · javiereguiluz · commit b20c28a2a2e0 · 2022-06-17T09:52:05.000+02:00
* 4.4:
  remove outdated references to the master branch
  [Form] Fix undefined variable
diff --git a/_build/maintainer_guide.rst b/_build/maintainer_guide.rst
@@ -39,22 +39,22 @@ contributes again, it's OK to mention some of the minor issues to educate them.
 
     $ gh merge 11059
 
-      Working on symfony/symfony-docs (branch master)
+      Working on symfony/symfony-docs (branch 5.4)
       Merging Pull Request 11059: dmaicher/patch-3
 
       ...
 
       # This is important!! Say NO to push the changes now
       Push the changes now? (Y/n) n
-      Now, push with: git push gh "master" refs/notes/github-comments
+      Now, push with: git push gh "5.4" refs/notes/github-comments
 
       # Now, open your editor and make the needed changes ...
 
       $ git commit -a
       # Use "Minor reword", "Minor tweak", etc. as the commit message
 
       # now run the 'push' command shown above by 'gh' (it's different each time)
-      $ git push gh "master" refs/notes/github-comments
+      $ git push gh "5.4" refs/notes/github-comments
 
 Merging Pull Requests
 ---------------------
diff --git a/contributing/code/maintenance.rst b/contributing/code/maintenance.rst
@@ -41,14 +41,14 @@ Besides bug fixes, other minor changes can be accepted in a patch version:
 
 * **Coding standard and refactoring**: Coding standard fixes or code
   refactoring are not recommended but can be accepted for consistency with the
-  existing code base, if they are not too invasive, and if merging them on
-  master would not lead to complex branch merging;
+  existing code base, if they are not too invasive, and if merging them into
+  higher branches would not lead to complex branch merging;
 
 * **Tests**: Tests that increase the code coverage can be added.
 
 Anything not explicitly listed above should be done on the next minor or major
-version instead (aka the *master* branch). For instance, the following changes
-are never accepted in a patch version:
+version instead. For instance, the following changes are never accepted in a
+patch version:
 
 * **New features**;
 
diff --git a/contributing/documentation/format.rst b/contributing/documentation/format.rst
@@ -201,12 +201,12 @@ For a deprecation use the ``.. deprecated:: 5.x`` directive:
 
         ... ... ... was deprecated in Symfony 5.2.
 
-Whenever a new major version of Symfony is released (e.g. 6.0, 7.0, etc),
-a new branch of the documentation is created from the ``master`` branch.
-At this point, all the ``versionadded`` and ``deprecated`` tags for Symfony
-versions that have a lower major version will be removed. For example, if
-Symfony 6.0 were released today, 5.0 to 5.4 ``versionadded`` and ``deprecated``
-tags would be removed from the new ``6.0`` branch.
+Whenever a new major version of Symfony is released (e.g. 6.0, 7.0, etc), a new
+branch of the documentation is created from the ``x.4`` branch of the previous
+major version. At this point, all the ``versionadded`` and ``deprecated`` tags
+for Symfony versions that have a lower major version will be removed. For
+example, if Symfony 6.0 were released today, 5.0 to 5.4 ``versionadded`` and
+``deprecated`` tags would be removed from the new ``6.0`` branch.
 
 .. _reStructuredText: https://docutils.sourceforge.io/rst.html
 .. _Sphinx: https://www.sphinx-doc.org/
diff --git a/form/unit_testing.rst b/form/unit_testing.rst
@@ -59,7 +59,7 @@ The simplest ``TypeTestCase`` implementation looks like the following::
             $form = $this->factory->create(TestedType::class, $model);
 
             $expected = new TestObject();
-            // ...populate $object properties with the data stored in $formData
+            // ...populate $expected properties with the data stored in $formData
 
             // submit the data to the form directly
             $form->submit($formData);
