Request for Comments: Backwards Compatibility

• Version: 1.0
• Date: 2011-09-25
• Author: Alan Knowles alan_k@php.com
• Status: Under Discussion
• First Published at: http://wiki.php.net/rfc/backwards_compatibility
• Other formats ..

Breaking 'BC' in PHP is always controversial, as it breaks code that has been running previously causing code or server maintainers to either revert to a previous version, or attempt to fix the code affected.

PHP has historically been pretty good at maintaining BC, however like all pieces of software this is a fine balancing act between the realities of development and the needs of developers.

Opinion: As PHP faces more competition in the Core market of Server side scripting languages, The knowldge that PHP is a mature language that will run code developed today for at least 6-8 years (and maybe more) without changes being required is a key selling point. This is something that less mature languages can not hope to offer.

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.

“Class A Reasons”

• New features that are not mature yet. (usually flagged as experimental)
• Behaviour between documentation clearly differs from actual behavior.

“Class B Reasons”

• Fundimental engine changes
• Features that can not be supported (due to unmainted external libraries)

“Class C Reasons”

• Documented behaviour is unclear.
• Consistancy between a group of related functions

• “Class A” - instanceof - when introduced the idea was that it would use the autoloader to check variable string values. this proved to be problematic, and was removed.
• “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 '&' when copying introduced more failure points and difficult to diagnose bugs in end user code.
• “Class B” - ereg - uses a library that is not being developed or maintained, so bug reports could not be addressed upstream.

• Class A - At any time.
• Class B - Must have have a consensus among developers (normally by RFC/vote).
• Class C - Must pass the some basic tests (voting is essential)
  • Does it affect a number of end users (eyeball / grep various open source projects, PEAR, Syphony, Zend and various CMS / large open source projects)
  • Can a “Forward Compatility workaround” be implemented by end users trivially based on a Depreciation warning.

For Class B and C reasons, an RFC should be proposed.

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 plan to implement this (eg. timespan for DEPRECIATION warnings and when it is likely to be completed)
• 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.

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..

Created - Sept 2011