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/05/21 01:09]
pajoye [Feature selection and development]
rfc:releaseprocess [2017/09/22 13:28] (current)
Line 1: Line 1:
 ====== Request for Comments: Release Process ====== ====== Request for Comments: Release Process ======
-  * Version: 0.1+  * Version: 0.6
   * 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 +  * 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 12: Line 12:
  
   * a clear release cycle, periodic   * a clear release cycle, periodic
-  * a transparent decision process for the feature additions, via the RFCs and a transparent ​but anonymous ​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 93: Line 97:
  
  
-  * January+  * June
     * Decisions which features or changes will be in the next release     * Decisions which features or changes will be in the next release
     * 1st release alpha (may have many alpha)     * 1st release alpha (may have many alpha)
   * At least one release per month, more at wish   * At least one release per month, more at wish
-  * March, 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
-  * June, Final+  * November, Final
     * Last RC taken as final, golden release (no change between the last RC and the final version)     * Last RC taken as final, golden release (no change between the last RC and the final version)
  
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)
  
-NB: the poll plugin ​will be installed ​shortly+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
 +  * Added RMs sections
 +  * Public votes instead of private
 +  * Added new proposers
rfc/releaseprocess.1305940158.txt.gz · Last modified: 2017/09/22 13:28 (external edit)