rfc:releaseprocess

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
rfc:releaseprocess [2011/06/07 19:39]
stas [Feature selection and development]
rfc:releaseprocess [2017/09/22 13:28] (current)
Line 3: Line 3:
   * Date: 2010-11-22   * Date: 2010-11-22
   * Author: Felipe Pena, Etienne Kneuss, Stanislav Malyshev, Gustavo André dos Santos Lopes, David Soria Parra, Christian Stocker, Rob Richards, Pierre Joye, Zeev Suraski, Ilia Alshanetsky   * Author: Felipe Pena, Etienne Kneuss, Stanislav Malyshev, Gustavo André dos Santos Lopes, David Soria Parra, Christian Stocker, Rob Richards, Pierre Joye, Zeev Suraski, Ilia Alshanetsky
-  * Status: ​Under Discussion+  * Status: ​Accepted, [[rfc:​releaseprocess:​vote|Voting results]]
  
 ===== Introduction ===== ===== Introduction =====
Line 13: Line 13:
   * a clear release cycle, periodic   * a clear release cycle, periodic
   * a transparent decision process for the feature additions, via the RFCs and a transparent and public vote   * a transparent decision process for the feature additions, via the RFCs and a transparent and public vote
-  * which changes can be done during a release lifetime (BC breaks, ​bugs fixes, security fixes, etc.)+  * which changes can be done during a release lifetime (BC breaks, ​bug fixes, security fixes, etc.)
   * a transparent way to choose release managers for a given release   * a transparent way to choose release managers for a given release
   * a better usage of bugs.php.net to track each change, addition, bug fixes (security incl.) or other various tasks related to a release   * a better usage of bugs.php.net to track each change, addition, bug fixes (security incl.) or other various tasks related to a release
Line 26: Line 26:
   * Yearly release cycle   * Yearly release cycle
   * 3 years release life cycle   * 3 years release life cycle
-    * 2 years bugs fixes only+    * 2 years bug fixes only
     * 1 year security fixes only     * 1 year security fixes only
  
Line 34: Line 34:
  
    * x.y.z to x.y.z+1    * x.y.z to x.y.z+1
-      * Bugs fixes only (with a room for exceptions on a case by case basis and only for small self contained features additions).+      * Bugfixes ​only (with a room for exceptions on a case by case basis and only for small self contained features additions).
       * Extensions support can't be removed (like move them to pecl)       * Extensions support can't be removed (like move them to pecl)
       * Backward compatibility must be kept (internals and userland)       * Backward compatibility must be kept (internals and userland)
       * ABI/API compatibility must be kept (internals)       * ABI/API compatibility must be kept (internals)
    * x.y.z to x.y+1.z    * x.y.z to x.y+1.z
-      * Bugs fixes+      * Bugfixes
       * New features       * New features
       * Extensions support can be ended (moved to pecl)       * Extensions support can be ended (moved to pecl)
       * Backward compatibility must be kept       * Backward compatibility must be kept
-      * API compatibility must be kept (internals and userland) +      * API compatibility must be kept (userland) 
-      * ABI can be broken (internals)+      * ABI and API can be broken (internals), src compatibility should be kept if possible, while breakages are allowed
    * x.y.z to x+1.0.0    * x.y.z to x+1.0.0
-      * Bugs fixes+      * Bugfixes
       * New features       * New features
       * Extensions support can be ended (moved to pecl)       * Extensions support can be ended (moved to pecl)
Line 53: Line 53:
       * ABI can be broken (internals)       * ABI can be broken (internals)
  
-It is critical to understand the consequences of breaking BC, APIs or ABIs. It should not be done for the sake of doing it. RFCs explaining the reasoning behind a breakage and the consequences along with test cases and patch(es) should help.+It is critical to understand the consequences of breaking BC, APIs or ABIs (only internals related). It should not be done for the sake of doing it. RFCs explaining the reasoning behind a breakage and the consequences along with test cases and patch(es) should help. 
 + 
 +See the following links for explanation about API and ABI: 
 +  * http://​en.wikipedia.org/​wiki/​Application_programming_interface  
 +  * http://​en.wikipedia.org/​wiki/​Application_binary_interface
 ==== Example time line with only one major version at a time  ==== ==== Example time line with only one major version at a time  ====
 <​code>​ <​code>​
 **** pre release phase **** pre release phase
-++++ release lifetime with all bugs fixes, no feature addition+++++ release lifetime with all bug fixes, no feature addition
 ---- release lifetime security ​ fixes only ---- release lifetime security ​ fixes only
 D    EOL D    EOL
Line 99: Line 103:
   * September, RC phases, biweekly release   * September, RC phases, biweekly release
     * each RC should go through the QA before being published     * each RC should go through the QA before being published
-      * usually2 ​days+      * usually 2 days
       * running the various test suites (phpt, custom real life tests, platform specific tests). Some tests need a day to run       * running the various test suites (phpt, custom real life tests, platform specific tests). Some tests need a day to run
   * November, Final   * November, Final
Line 120: Line 124:
   * other sub projects like pear (yes, no)   * other sub projects like pear (yes, no)
  
-We have voting plugin for dokuwiki (doodle2) that allows voting on the wiki.+We have voting plugin for dokuwiki (doodle2) that allows voting on the wiki (installed).
  
 ===== RMs Role ===== ===== RMs Role =====
Line 129: Line 133:
   * Create a roadmap and planing according to this RFC   * Create a roadmap and planing according to this RFC
   * Package the releases (test and final releases)   * Package the releases (test and final releases)
-  * Decide which bug fixes can be apply to a release, ​inside ​the cases defined in this RFC+  * Decide which bug fixes can be applied ​to a release, ​within ​the cases defined in this RFC
  
 But they are not: But they are not:
Line 176: Line 180:
  
 ===== Changelog ===== ===== Changelog =====
 +2011/6/20
 +  * Added API/ABI clarification
 +  * Added vote code in /vote
 +
 +
 2011/5/24 2011/5/24
   * Added RMs sections   * Added RMs sections
   * Public votes instead of private   * Public votes instead of private
   * Added new proposers   * Added new proposers
- 
rfc/releaseprocess.1307475549.txt.gz · Last modified: 2017/09/22 13:28 (external edit)