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: 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) | ||
Line 46: | Line 46: | ||
* ABI and API can be broken (internals), src compatibility should be kept if possible, while breakages are allowed | * 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 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://en.wikipedia.org/wiki/Application_programming_interface | * http://en.wikipedia.org/wiki/Application_programming_interface | ||
* http://en.wikipedia.org/wiki/Application_binary_interface | * http://en.wikipedia.org/wiki/Application_binary_interface | ||
Line 61: | Line 61: | ||
<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 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 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 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, 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 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)