minor #7462 fixed Backward Compatibility typo (fabpot)

This PR was merged into the 2.7 branch. Discussion ---------- fixed Backward Compatibility typo "backward compatibility", not "backwards compatibility" (see https://en.wikipedia.org/wiki/Backward_compatibility). Commits ------- d06bf10 fixed Backward Compatibility typo

Author: weaverryan

console/verbosity.rst

@@ -66,7 +66,7 @@ verbosity levels::
  These semantic methods are defined in the ``OutputInterface`` starting from
  Symfony 3.0. In previous Symfony versions they are defined in the different
  implementations of the interface (e.g. :class:`Symfony\\Component\\Console\\Output\\Output`)
- in order to keep backwards compatibility.
+ in order to keep backward compatibility.
 
 When the quiet level is used, all output is suppressed as the default
 :method:`Symfony\\Component\\Console\\Output\\Output::write` method returns

contributing/code/bc.rst

@@ -1,11 +1,11 @@
-Our Backwards Compatibility Promise
-===================================
+Our Backward Compatibility Promise
+==================================
 
 Ensuring smooth upgrades of your projects is our first priority. That's why
-we promise you backwards compatibility (BC) for all minor Symfony releases.
+we promise you backward compatibility (BC) for all minor Symfony releases.
 You probably recognize this strategy as `Semantic Versioning`_. In short,
 Semantic Versioning means that only major releases (such as 2.0, 3.0 etc.) are
-allowed to break backwards compatibility. Minor releases (such as 2.5, 2.6 etc.)
+allowed to break backward compatibility. Minor releases (such as 2.5, 2.6 etc.)
 may introduce new features, but must do so without breaking the existing API of
 that release branch (2.x in the previous example).
 
@@ -14,7 +14,7 @@ that release branch (2.x in the previous example).
  This promise was introduced with Symfony 2.3 and does not apply to previous
  versions of Symfony.
 
-However, backwards compatibility comes in many different flavors. In fact, almost
+However, backward compatibility comes in many different flavors. In fact, almost
 every change that we make to the framework can potentially break an application.
 For example, if we add a new method to a class, this will break an application
 which extended this class and added the same method, but with a different
@@ -54,10 +54,10 @@ sticks to these rules.
 If you implement an interface, we promise that we won't ever break your code.
 
 The following table explains in detail which use cases are covered by our
-backwards compatibility promise:
+backward compatibility promise:
 
 +-----------------------------------------------+-----------------------------+
-| Use Case | Backwards Compatibility |
+| Use Case | Backward Compatibility  |
 +===============================================+=============================+
 | **If you...** | **Then we guarantee BC...** |
 +-----------------------------------------------+-----------------------------+
@@ -88,10 +88,10 @@ public methods and properties.
  not be accessed by your own code.
 
 To be on the safe side, check the following table to know which use cases are
-covered by our backwards compatibility promise:
+covered by our backward compatibility promise:
 
 +-----------------------------------------------+-----------------------------+
-| Use Case | Backwards Compatibility |
+| Use Case | Backward Compatibility  |
 +===============================================+=============================+
 | **If you...** | **Then we guarantee BC...** |
 +-----------------------------------------------+-----------------------------+

contributing/community/releases.rst

@@ -140,10 +140,10 @@ Version Feature Freeze Release End of Maintenance End of Life
 .. [2] Symfony 2.8 is the last version of the Symfony 2.x branch.
 .. [3] Symfony 3.0 is the first version to use the new release process based on five minor releases.
 
-Backwards Compatibility
------------------------
+Backward Compatibility
+----------------------
 
-Our :doc:`Backwards Compatibility Promise </contributing/code/bc>` is very
+Our :doc:`Backward Compatibility Promise </contributing/code/bc>` is very
 strict and allows developers to upgrade with confidence from one minor version
 of Symfony to the next one.
 

contributing/community/reviews.rst

@@ -22,7 +22,7 @@ status:
 * **Pull Requests**: Pull requests contain code that fixes a bug or implements
  new functionality. Reviews of pull requests ensure that they are implemented
  properly, are covered by test cases, don't introduce new bugs and maintain
- backwards compatibility.
+ backward compatibility.
 
 Note that **anyone who has some basic familiarity with Symfony and PHP can
 review bug reports and pull requests**. You don't need to be an expert to help.
@@ -140,12 +140,12 @@ Pick a pull request from the `PRs in need of review`_ and follow these steps:
  * Does the PR contain automated tests? Do those tests cover all relevant
  edge cases?
  * Does the PR contain sufficient comments to easily understand its code?
- * Does the code break backwards compatibility? If yes, does the PR header say
+ * Does the code break backward compatibility? If yes, does the PR header say
  so?
  * Does the PR contain deprecations? If yes, does the PR header say so? Does
  the code contain ``trigger_error()`` statements for all deprecated
  features?
- * Are all deprecations and backwards compatibility breaks documented in the
+ * Are all deprecations and backward compatibility breaks documented in the
  latest UPGRADE-X.X.md file? Do those explanations contain "Before"/"After"
  examples with clear upgrade instructions?
 

contributing/map.rst.inc

@@ -7,7 +7,7 @@
  * :doc:`The Core Team </contributing/code/core_team>`
  * :doc:`Security </contributing/code/security>`
  * :doc:`Tests </contributing/code/tests>`
- * :doc:`Backwards Compatibility </contributing/code/bc>`
+ * :doc:`Backward Compatibility </contributing/code/bc>`
  * :doc:`Coding Standards</contributing/code/standards>`
  * :doc:`Code Conventions</contributing/code/conventions>`
  * :doc:`Git</contributing/code/git>`

setup/bundles.rst

@@ -5,7 +5,7 @@ Upgrading a Third-Party Bundle for a Major Symfony Version
 ==========================================================
 
 Symfony 3 was released on November 2015. Although this version doesn't contain
-any new features, it removes all the backwards compatibility layers included in
+any new features, it removes all the backward compatibility layers included in
 the previous 2.8 version. If your bundle uses any deprecated feature and it's
 published as a third-party bundle, applications upgrading to Symfony 3 will no
 longer be able to use it.

setup/upgrade_major.rst

@@ -6,7 +6,7 @@ Upgrading a Major Version (e.g. 2.7.0 to 3.0.0)
 
 Every two years, Symfony releases a new major version release (the first number
 changes). These releases are the trickiest to upgrade, as they are allowed to
-break backwards compatibility. However, Symfony makes this upgrade process as
+break backward compatibility. However, Symfony makes this upgrade process as
 smooth as possible.
 
 This means that you can update most of your code before the major release is

setup/upgrade_minor.rst

@@ -5,8 +5,8 @@ Upgrading a Minor Version (e.g. 2.5.3 to 2.6.1)
 ===============================================
 
 If you're upgrading a minor version (where the middle number changes), then
-you should *not* encounter significant backwards compatibility changes. For
-details, see the :doc:`Symfony backwards compatibility promise </contributing/code/bc>`.
+you should *not* encounter significant backward compatibility changes. For
+details, see the :doc:`Symfony backward compatibility promise </contributing/code/bc>`.
 
 However, some backwards-compatibility breaks *are* possible and you'll learn in
 a second how to prepare for them.