rfc:releaseprocess
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
rfc:releaseprocess [2011/06/20 12:05] – [Feature selection and development] pajoye | rfc: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: | + | * Status: |
===== 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, | + | * 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) | ||
Line 46: | Line 46: | ||
* ABI and API can be broken (internals), | * ABI and API can be broken (internals), | ||
* 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:// | * http:// | ||
* http:// | * http:// | ||
Line 61: | Line 61: | ||
< | < | ||
**** 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 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 | + | * 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, | + | * Decide which bug fixes can be applied |
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.1308571525.txt.gz · Last modified: 2017/09/22 13:28 (external edit)