Merge branch '4.1' into 4.2

* 4.1:
  Switch to 3.4 as oldest maintained branch
  Minor tweaks
  Changing the wording around module.exports
  FIX: Clarify best_practices/creating-the-project.rst

Author: javiereguiluz

README.markdown

@@ -7,8 +7,8 @@ Contributing
 ------------
 
 >**Note**
->Unless you're documenting a feature that was introduced *after* Symfony 2.8
->(e.g. in Symfony 3.4), all pull requests must be based off of the **2.8** branch,
+>Unless you're documenting a feature that was introduced *after* Symfony 3.4
+>(e.g. in Symfony 4.2), all pull requests must be based off of the **3.4** branch,
 >**not** the master or older branches.
 
 We love contributors! For more information on how you can contribute to the

best_practices/creating-the-project.rst

@@ -48,7 +48,8 @@ Structuring the Application
 ---------------------------
 
 After creating the application, enter the ``blog/`` directory and you'll see a
-number of files and directories generated automatically:
+number of files and directories generated automatically. These are the most
+important ones:
 
 .. code-block:: text
 

contributing/code/patches.rst

@@ -106,7 +106,7 @@ Choose the right Branch
 Before working on a patch, you must determine on which branch you need to
 work:
 
-* ``2.8``, if you are fixing a bug for an existing feature or want to make a
+* ``3.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
   </contributing/code/maintenance>` (you may have to choose a higher branch if
   the feature you are fixing was introduced in a later version);
@@ -117,7 +117,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.8`` branch, the patch will also be applied by the core team on
+    for the ``3.4`` branch, the patch will also be applied by the core team on
     the ``master`` branch.
 
 Create a Topic Branch
@@ -130,18 +130,18 @@ topic branch:
 
     $ git checkout -b BRANCH_NAME master
 
-Or, if you want to provide a bugfix for the ``2.8`` branch, first track the remote
-``2.8`` branch locally:
+Or, if you want to provide a bugfix for the ``3.4`` branch, first track the remote
+``3.4`` branch locally:
 
 .. code-block:: terminal
 
-    $ git checkout -t origin/2.8
+    $ git checkout -t origin/3.4
 
-Then create a new branch off the ``2.8`` branch to work on the bugfix:
+Then create a new branch off the ``3.4`` branch to work on the bugfix:
 
 .. code-block:: terminal
 
-    $ git checkout -b BRANCH_NAME 2.8
+    $ git checkout -b BRANCH_NAME 3.4
 
 .. tip::
 
@@ -245,7 +245,7 @@ while to finish your changes):
 
 .. tip::
 
-    Replace ``master`` with the branch you selected previously (e.g. ``2.8``)
+    Replace ``master`` with the branch you selected previously (e.g. ``3.4``)
     if you are working on a bugfix
 
 When doing the ``rebase`` command, you might have to fix merge conflicts.
@@ -272,8 +272,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.8`` if you want
-    the core team to pull a bugfix based on the ``2.8`` branch.
+    Take care to point your pull request towards ``symfony:3.4`` if you want
+    the core team to pull a bugfix based on the ``3.4`` branch.
 
 To ease the core team work, always include the modified components in your
 pull request message, like in:
@@ -344,7 +344,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.8``, don't merge; and force the push to the origin:
+``upstream/3.4``, don't merge; and force the push to the origin:
 
 .. code-block:: terminal
 

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/2.8
+    $ git checkout -b improve_install_article upstream/3.4
 
 In this example, the name of the branch is ``improve_install_article`` and the
-``upstream/2.8`` value tells Git to create this branch based on the ``2.8``
+``upstream/3.4`` value tells Git to create this branch based on the ``3.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 ``2.8`` branch. If you are instead documenting a
+the error. Nowadays this is the ``3.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 ``2.8``, which is the branch that you selected
+the **base** branch should be the ``3.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/2.8
+    $ git checkout -b my_changes upstream/3.4
 
     # ... do your changes
 
@@ -288,8 +288,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.8,
-your changes should always be based on the ``2.8`` branch. Documentation managers
+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
 will use the necessary Git-magic to also apply your changes to all the active
 branches of the documentation.
 

frontend/encore/simple-example.rst

@@ -180,8 +180,8 @@ The import and export Statements
 --------------------------------
 
 Instead of using ``require`` and ``module.exports`` like shown above, JavaScript
-has an alternate syntax, which is a more accepted standard. Choose whichever you
-want: they do the same thing.
+provides an alternate syntax based on the `ECMAScript 6 modules`_ that includes
+the ability to use dynamic imports.
 
 To export values using the alternate syntax, use ``exports``:
 
@@ -345,3 +345,4 @@ Encore support many more features! For a full list of what you can do, see
 `Encore's index.js file`_. Or, go back to :ref:`list of Encore articles <encore-toc>`.
 
 .. _`Encore's index.js file`: https://github.com/symfony/webpack-encore/blob/master/index.js
+.. _`ECMAScript 6 modules`: https://hacks.mozilla.org/2015/08/es6-in-depth-modules/