From d06bf109f693c787b60a8a65d31665d415e3bbec Mon Sep 17 00:00:00 2001 From: Fabien Potencier Date: Sun, 12 Feb 2017 17:00:10 +0100 Subject: [PATCH] fixed Backward Compatibility typo --- console/verbosity.rst | 2 +- contributing/code/bc.rst | 18 +++++++++--------- contributing/community/releases.rst | 6 +++--- contributing/community/reviews.rst | 6 +++--- contributing/map.rst.inc | 2 +- setup/bundles.rst | 2 +- setup/upgrade_major.rst | 2 +- setup/upgrade_minor.rst | 4 ++-- 8 files changed, 21 insertions(+), 21 deletions(-) diff --git a/console/verbosity.rst b/console/verbosity.rst index b6b9e1af8fe..b5e776592bb 100644 --- a/console/verbosity.rst +++ b/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 diff --git a/contributing/code/bc.rst b/contributing/code/bc.rst index f11ab49ba08..d2cf618ef70 100644 --- a/contributing/code/bc.rst +++ b/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...** | +-----------------------------------------------+-----------------------------+ diff --git a/contributing/community/releases.rst b/contributing/community/releases.rst index 8ecc57ff6af..76a02fd8c14 100644 --- a/contributing/community/releases.rst +++ b/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 ` is very +Our :doc:`Backward Compatibility Promise ` is very strict and allows developers to upgrade with confidence from one minor version of Symfony to the next one. diff --git a/contributing/community/reviews.rst b/contributing/community/reviews.rst index 2e498f489bd..b64fd4b8832 100644 --- a/contributing/community/reviews.rst +++ b/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? diff --git a/contributing/map.rst.inc b/contributing/map.rst.inc index 22f96075c8e..1b8fe98c219 100644 --- a/contributing/map.rst.inc +++ b/contributing/map.rst.inc @@ -7,7 +7,7 @@ * :doc:`The Core Team ` * :doc:`Security ` * :doc:`Tests ` - * :doc:`Backwards Compatibility ` + * :doc:`Backward Compatibility ` * :doc:`Coding Standards` * :doc:`Code Conventions` * :doc:`Git` diff --git a/setup/bundles.rst b/setup/bundles.rst index b5bb9baf4db..ba346ecc7fe 100644 --- a/setup/bundles.rst +++ b/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. diff --git a/setup/upgrade_major.rst b/setup/upgrade_major.rst index e81684c35fc..879fb6b900a 100644 --- a/setup/upgrade_major.rst +++ b/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 diff --git a/setup/upgrade_minor.rst b/setup/upgrade_minor.rst index dfdd5858684..7c9f185a0a0 100644 --- a/setup/upgrade_minor.rst +++ b/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 `. +you should *not* encounter significant backward compatibility changes. For +details, see the :doc:`Symfony backward compatibility promise `. However, some backwards-compatibility breaks *are* possible and you'll learn in a second how to prepare for them.