rfc:releaseprocess
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
rfc:releaseprocess [2011/05/17 15:08] – [Release managers selection] pajoye | rfc:releaseprocess [2011/06/29 12:26] – remove paragraph that votes are open dsp | ||
---|---|---|---|
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 | + | * 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: | + | * Status: |
===== 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 | + | * a transparent decision process for the feature additions, via the RFCs and a transparent |
- | * which changes can be done during a release lifetime (BC breaks, | + | * which changes can be done during a release lifetime (BC breaks, |
* 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 |
* 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:// | ||
+ | * http:// | ||
==== Example time line with only one major version at a time ==== | ==== Example time line with only one major version at a time ==== | ||
< | < | ||
**** 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 | ---- release lifetime security | ||
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 | * usually2 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 110: | Line 114: | ||
Features can use branch(es) if necessary, doing so will minimize the impact of other commits and changes on the development of a specific feature (or the other way ' | Features can use branch(es) if necessary, doing so will minimize the impact of other commits and changes on the development of a specific feature (or the other 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 an anonymous way (who votes what won't be made public). | + | 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 |
+ | |||
+ | See also [[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 | + | We have voting |
===== RMs Role ===== | ===== RMs Role ===== | ||
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.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1