rfc:backwards_compatibility

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
rfc:backwards_compatibility [2011/09/25 01:24] – update alan_krfc:backwards_compatibility [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 1: Line 1:
-====== Request for Comments: How to write RFCs ======+====== Request for Comments: Backwards Compatibility ======
   * Version: 1.0   * Version: 1.0
   * Date: 2011-09-25   * Date: 2011-09-25
Line 45: Line 45:
  
  
-===== When an BC   be broken =====+===== When can BC   be broken =====
  
   * Class A - At any time.   * Class A - At any time.
   * Class B - Must have have a consensus among developers (normally by RFC/vote).   * Class B - Must have have a consensus among developers (normally by RFC/vote).
-  * Class C - Must pass the some basic tests+  * 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)      * 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.      * Can a "Forward Compatility workaround" be implemented by end users trivially based on a Depreciation warning.
rfc/backwards_compatibility.1316913869.txt.gz · Last modified: 2017/09/22 13:28 (external edit)