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/07 19:38] – [Feature selection and development] stasrfc: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+  * 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 111: Line 115:
  
 The change to what we have now is the voting process. It will not happen anymore on the mailing list but in the RFCs directly, for php.net members, in a public way. The change to what we have now is the voting process. It will not happen anymore on the mailing list but in the RFCs directly, for php.net members, in a public way.
 +
 +See also [[rfc::voting|the voting RFC]].
  
 The question for this section is about who will be allowed to vote: The question for this section is about who will be allowed to vote:
Line 118: 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 127: 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 174: 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.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1