rfc:backwards_compatibility
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
| rfc:backwards_compatibility [2011/09/25 01:18] – created alan_k | rfc:backwards_compatibility [2017/09/22 13:28] (current) – external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Request for Comments: | + | ====== Request for Comments: |
| * Version: 1.0 | * Version: 1.0 | ||
| * Date: 2011-09-25 | * Date: 2011-09-25 | ||
| - | * Author: Alan Knowles <alan@akbkhome.com> | + | * Author: Alan Knowles <alan_k@php.com> |
| * Status: Under Discussion | * Status: Under Discussion | ||
| * First Published at: http:// | * First Published at: http:// | ||
| Line 18: | Line 18: | ||
| So with this in mind, It would be helpfull for end users, and php core developers to have a common understanding of when, why and if BC may be broken. | So with this in mind, It would be helpfull for end users, and php core developers to have a common understanding of when, why and if BC may be broken. | ||
| - | ==== Reasons for BC Changes. | + | ===== Reasons for BC Changes. |
| "Class A Reasons" | "Class A Reasons" | ||
| - | * New features that are not mature yet. (usually flagged as experimental) | + | |
| + | * New features that are not mature yet. (usually flagged as experimental) | ||
| + | * Behaviour between documentation clearly differs from actual behavior. | ||
| + | |||
| "Class B Reasons" | "Class B Reasons" | ||
| - | * Fundimental engine changes | + | |
| - | * Features that can not be supported (due to unmainted external libraries) | + | * Fundimental engine changes |
| + | * Features that can not be supported (due to unmainted external libraries) | ||
| "Class C Reasons" | "Class C Reasons" | ||
| - | * Behaviour between documentation differs from actual behaviour. | + | |
| - | * Documented behaviour is unclear. | + | * Documented behaviour is unclear. |
| - | * Consistancy between a group of related functions | + | * Consistancy between a group of related functions |
| ===== Examples ===== | ===== Examples ===== | ||
| - | * "Class A" - instanceof - when introduced the idea was that it would use the autoloader to check variable string values. this proved to be problematic, | + | |
| - | * "Class B" - PHP5 broke most PHP4 object based code that relied on copy on assign, as the object model changed. This became necessary as PHP applications where becomming more complex and the need to alias '&' | + | * "Class B" - PHP5 broke most PHP4 object based code that relied on copy on assign, as the object model changed. This became necessary as PHP applications where becomming more complex and the need to alias '&' |
| - | * "Class B" - ereg - uses a library that is not being developed or maintained, so bug reports could not be addressed upstream. | + | * "Class B" - ereg - uses a library that is not being developed or maintained, so bug reports could not be addressed upstream. |
| - | ===== When an BC be broken ===== | + | ===== When can BC be broken ===== |
| - | * Class A - At any time. | + | |
| - | * Class B - Must have have a consensus among developers (normally by RFC/ | + | * Class B - Must have have a consensus among developers (normally by RFC/ |
| - | * Class C - Must pass the some basic tests | + | * Class C - Must pass the some basic tests (voting is essential) |
| - | | + | |
| - | | + | |
| - | ==== Process for introducing BC. ==== | + | ===== Process for introducing BC. ===== |
| For Class B and C reasons, an RFC should be proposed. | For Class B and C reasons, an RFC should be proposed. | ||
| Line 56: | Line 60: | ||
| It should include: | It should include: | ||
| - | * Summary of the problem and the reason for the break. | + | |
| - | * a summary of who it affects and the likely impact, what code has been looked at (eg. frameworks, CMS large project etc.) | + | * a summary of who it affects and the likely impact, what code has been looked at (eg. frameworks, CMS large project etc.) |
| - | * a plan to implement this (eg. timespan for DEPRECIATION warnings and when it is likely to be completed) | + | * a plan to implement this (eg. timespan for DEPRECIATION warnings and when it is likely to be completed) |
| - | * roughly which version it will affect. | + | * roughly which version it will affect. |
| Once discussed / completed, a vote should occur. Obviously if it fails, another vote can be called again if the proposer wishes. | Once discussed / completed, a vote should occur. Obviously if it fails, another vote can be called again if the proposer wishes. | ||
| - | ==== Other notes ==== | + | ===== Other notes ===== |
| Depreciation warnings should point to the RFC discussing the change. So users have a clear understanding of why it was done, and how to work around it.. | Depreciation warnings should point to the RFC discussing the change. So users have a clear understanding of why it was done, and how to work around it.. | ||
| Line 69: | Line 73: | ||
| ===== Changelog ===== | ===== Changelog ===== | ||
| - | Created - | + | Created - Sept 2011 |
rfc/backwards_compatibility.1316913511.txt.gz · Last modified: 2017/09/22 13:28 (external edit)