8000 [Review] Added detailed Backwards Compatibility Promise text by webmozart · Pull Request #3439 · symfony/symfony-docs · GitHub
[go: up one dir, main page]

Skip to content

[Review] Added detailed Backwards Compatibility Promise text #3439

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 39 commits into from
Feb 20, 2014
Merged
Changes from 1 commit
Commits
Show all changes
39 commits
Select commit Hold shift + click to select a range
840073c
Added detailed BC promise text
webmozart Jan 7, 2014
7320ed0
Updated BC promise to be valid as of Symfony 2.3
webmozart Jan 7, 2014
dacd7ce
Rearranged rules to be more easily understandable
webmozart Jan 7, 2014
79ca9f7
Added information about type compatibility
webmozart Jan 8, 2014
0e925cb
Added tables with safe operations
webmozart Jan 8, 2014
44ecf16
Fixed: No parameters must be added (ever) to API class methods
webmozart Jan 8, 2014
afadaab
Changed: The last parameters of a method may be removed
webmozart Jan 8, 2014
345410c
Rearranged safe operations to make more sense
webmozart Jan 8, 2014
a3ad08c
Removed most of the "cannot" statements which are repeated in the tab…
webmozart Jan 8, 2014
31ab2db
Improved wording
webmozart Jan 8, 2014
502ed95
Added: Some breaking changes to unsafe operations are documented in t…
webmozart Jan 8, 2014
4c5a55d
Rearranged page to have different sections for different user bases
webmozart Jan 8, 2014
c6e850d
Language fixes
webmozart Jan 8, 2014
db76288
Fixed headings
webmozart Jan 8, 2014
54fd836
Language improvements
webmozart Jan 8, 2014
00c6ebe
Fixed safety statements
webmozart Jan 8, 2014
efd3911
Added that adding custom properties is not safe
webmozart Jan 8, 2014
dcbe79a
Improved wording
webmozart Jan 9, 2014
af3a645
Added note about requesting `@api` tags
webmozart Jan 9, 2014
be76644
Added information about internal classes and interfaces
webmozart Jan 9, 2014
dfb3e8b
Improved wording
webmozart Jan 9, 2014
8000
6501a35
Added information about changing return types that are classes or int…
webmozart Jan 9, 2014
0c6420f
Added information about changing parameter types
webmozart Jan 9, 2014
69768dd
Improved wording: use -> call, access
webmozart Jan 10, 2014
5a160c5
Added note about deprecated interfaces/classes
webmozart Jan 10, 2014
ef1f021
Added note about test classes
webmozart Jan 10, 2014
6d9edf1
Improved wording: Changed "safe" to "guaranteed"
webmozart Jan 23, 2014
8c6c7bf
Simplified usage description
webmozart Jan 23, 2014
4868452
Added prose about the difference between regular/API classes/interfaces
webmozart Jan 23, 2014
e11335f
Improved the wording of the "Using Symfony" section
webmozart Jan 24, 2014
25443c0
Improved table formatting
webmozart Feb 12, 2014
11bb879
Grammar
webmozart Feb 12, 2014
fd1d912
Typo
webmozart Feb 12, 2014
bdd3c03
Implemented changes suggested by @WouterJ
webmozart Feb 15, 2014
2320906
Extracted duplicated text into _api_tagging.rst.inc
webmozart Feb 15, 2014
90c4de6
Mentioned Semantic Versioning in the introduction
webmozart Feb 20, 2014
be2251c
Implemented @fabpot's comments
webmozart Feb 20, 2014
ce58ee9
Added rules for adding parent interfaces and moving methods/propertie…
webmozart Feb 20, 2014
0717192
Removed useless line break
webmozart Feb 20, 2014
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Added rules for adding parent interfaces and moving methods/propertie…
…s to parent interfaces/classes
  • Loading branch information
webmozart committed Feb 20, 2014
commit ce58ee9ea6a40a4e59e85568d7829c87169aae47
45 changes: 27 additions & 18 deletions contributing/code/bc.rst
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ Our Backwards 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.

You probably recognize this strategy as `Semantic Versioning`_. In short,
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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

3.0, etc.

allowed to break backwards compatibility. Minor releases (such as 2.5, 2.6 etc.)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2.6, etc. ?

may introduce new features, but must do so without breaking the existing API of
Expand Down Expand Up @@ -211,21 +211,22 @@ Type of Change Regular API
============================================== ============== ==============
Remove entirely No No
Change name or namespace No No
Add parent interface Yes [2]_ No
Add parent interface Yes [2]_ Yes [3]_
Remove parent interface No No
**Methods**
Add method Yes [2]_ No
Remove method No No
Change name No No
Move to parent interface Yes Yes
Add argument without a default value No No
Add argument with a default value Yes [2]_ No
Remove argument Yes [3]_ Yes [3]_
Remove argument Yes [4]_ Yes [4]_
Add default value to an argument Yes [2]_ No
Remove default value of an argument No No
Add type hint to an argument No No
Remove type hint of an argument Yes [2]_ No
Change argument type Yes [2]_ [4]_ No
Change return type Yes [2]_ [5]_ No
Change argument type Yes [2]_ [5]_ No
Change return type Yes [2]_ [6]_ No
============================================== ============== ==============

Changing Classes
Expand All @@ -241,17 +242,19 @@ Remove entirely No No
Make final Yes [2]_ No
Make abstract No No
Change name or namespace No No
Change parent class Yes [6]_ Yes [6]_
Change parent class Yes [7]_ Yes [7]_
Add interface Yes Yes
Remove interface No No
**Public Properties**
Add public property Yes Yes
Remove public property No No
Reduce visibility No No
Move to parent class Yes Yes
**Protected Properties**
Add protected property Yes Yes
Remove protected property Yes [2]_ No
Reduce visibility Yes [2]_ No
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should add lines about private properties and methods. My reasoning here is that you can access them from the outside via reflection. Everyone would agree that there no guarantee about those properties/methods, but as we are listing all possible cases here, it does not hurt to list all possibilities here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added notes about private properties and methods both in the "Using Symfony" and "Working on Symfony" sections.

Move to parent class Yes Yes
**Private Properties**
Add private property Yes Yes
Remove private property Yes Yes
Expand All @@ -260,34 +263,37 @@ Add constructor without mandatory arguments Yes [2]_ Yes [2]_
Remove constructor Yes [2]_ No
Reduce visibility of a public constructor No No
Reduce visibility of a protected constructor Yes [2]_ No
Move to parent class Yes Yes
**Public Methods**
Add public method Yes Yes
Remove public method No No
Change name No No
Reduce visibility No No
Move to parent class Yes Yes
Add argument without a default value No No
Add argument with a default value Yes [2]_ No
Remove argument Yes [3]_ Yes [3]_
Remove argument Yes [4]_ Yes [4]_
Add default value to an argument Yes [2]_ No
Remove default value of an argument No No
Add type hint to an argument Yes [7]_ No
Add type hint to an argument Yes [8]_ No
Remove type hint of an argument Yes [2]_ No
Change argument type Yes [2]_ [4]_ No
Change return type Yes [2]_ [5]_ No
Change argument type Yes [2]_ [5]_ No
Change return type Yes [2]_ [6]_ No
**Protected Methods**
Add protected method Yes Yes
Remove protected method Yes [2]_ No
Change name No No
Reduce visibility Yes [2]_ No
Move to parent class Yes Yes
Add argument without a default value Yes [2]_ No
Add argument with a default value Yes [2]_ No
Remove argument Yes [3]_ Yes [3]_
Remove argument Yes [4]_ Yes [4]_
Add default value to an argument Yes [2]_ No
Remove default value of an argument Yes [2]_ No
Add type hint to an argument Yes [2]_ No
Remove type hint of an argument Yes [2]_ No
Change argument type Yes [2]_ [4]_ No
Change return type Yes [2]_ [5]_ No
Change argument type Yes [2]_ [5]_ No
Change return type Yes [2]_ [6]_ No
**Private Methods**
Add private method Yes Yes
Remove private method Yes Yes
Expand All @@ -310,10 +316,13 @@ Change return type Yes Yes
.. [2] Should be avoided. When done, this change must be documented in the
UPGRADE file.

.. [3] Only the last argument(s) of a method may be removed, as PHP does not
.. [3] The added parent interface must not introduce any new methods that don't
exist in the interface already.

.. [4] Only the last argument(s) of a method may be removed, as PHP does not
care about additional arguments that you pass to a method.

.. [4] The argument type may only be changed to a compatible or less specific
.. [5] The argument type may only be changed to a compatible or less specific
type. The following type changes are allowed:

=================== ==================================================================
Expand All @@ -327,7 +336,7 @@ Change return type Yes Yes
interface ``<I>`` any superinterface of ``<I>``
=================== ==================================================================

.. [5] The return type may only be changed to a compatible or more specific
.. [6] The return type may only be changed to a compatible or more specific
type. The following type changes are allowed:

=================== ==================================================================
Expand All @@ -345,10 +354,10 @@ Change return type Yes Yes
interface ``<I>`` any subinterface or implementing class of ``<I>``
=================== ==================================================================

.. [6] When changing the parent class, the original parent class must remain an
.. [7] When changing the parent class, the original parent class must remain an
ancestor of the class.

.. [7] A type hint may only be added if passing a value with a different type
.. [8] A type hint may only be added if passing a value with a different type
previously generated a fatal error.

.. _Semantic Versioning: http://semver.org/
Expand Down
0