rfc:releaseprocess

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:releaseprocess [2011/06/20 16:42] – add link to voting dsprfc:releaseprocess [2017/09/22 13:28] (current) – external edit 127.0.0.1
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, [[rfc:releaseprocess:vote|Voting is open]]+  * 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)
Line 46: Line 46:
       * ABI and API can be broken (internals), src compatibility should be kept if possible, while breakages are allowed       * 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 55: Line 55:
 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. 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.
  
-Se the following links for explanation about API and ABI:+See the following links for explanation about API and ABI:
   * http://en.wikipedia.org/wiki/Application_programming_interface    * http://en.wikipedia.org/wiki/Application_programming_interface 
   * http://en.wikipedia.org/wiki/Application_binary_interface   * http://en.wikipedia.org/wiki/Application_binary_interface
Line 61: Line 61:
 <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 103: 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 133: 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 189: Line 189:
   * Public votes instead of private   * Public votes instead of private
   * Added new proposers   * Added new proposers
- 
rfc/releaseprocess.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1