rfc:releaseprocess
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
rfc:releaseprocess [2011/06/20 09:01] pajoye [Changelog] |
rfc:releaseprocess [2017/09/22 13:28] (current) |
||
|---|---|---|---|
| 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 124: | 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 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.1308560495.txt.gz · Last modified: 2017/09/22 13:28 (external edit)