On 04/08/2012 11:54 PM, Stas Malyshev wrote:
Hi! 5.4.1 will be the first release we're releasing using our new git setup. I would like to refine a process that we used to have for releases and make small tweaks hopefully to allow us more predictable release schedule and faster releases. What I am proposing is the following: 1. At the start of the cycle, PHP-5.4.X is branched off PHP-5.4. This is done on Monday/Tuesday (days can be tweaked back&forth a bit, but I assume we'll usually release on Thursday and count back from that). 2. This branch is checked by RM to compile, pass unit tests satisfactory, etc. and is released as 5.4.X RC1 3. In two weeks, if no critical errors is found in RC1, the same branch is released as 5.4.X. If any critical errors are found, RM cherry-pick fixes from 5.4 and release RC2 (RC3, etc. as needed) each two weeks after no criticial bugs are in 5.4.X branch. 4. In two more weeks, 5.4.(X+1) starts, provided we have changes from 5.4.X. If not, it is postponed by 2 weeks. It is somewhat different from what we did before as we never disallow committing into 5.4 and never allow (direct) committing into 5.4.X. This also means we will be releasing 2-weeks-old code (or maybe older), i.e. we will frequently be releasing code which has known (and fixed in other branch) bugs. This will also mean we will have to define what constitutes critical error, and maybe raise the bar a bit. I would like to propose the following criteria for critical error: 1. Compilation failure on a major platform (Linux, Windows, Mac, maybe some others at RM discretion) 2. Remotely exploitable security problem 3. Bug that breaks a large piece of widely used functionality, effective rendering it unusable (i.e. if somebody broke fopen() and it always returned false). Other things may be added on case-by-case basis but this will be the guidelines. All other changes go into the next release. I think doing it this way will allow us to have 5.4.X releases monthly as we planned in the release RFC. This will also mean that there would be almost constant lag between committing regular fix and releasing it, which may be larger than we had before. I think it won't be too bad if we had regular monthly releases. Comments?
Stas, I'm fine with this. I would like to see clarity on when fixes have been merged to the RC branch (git emails are still a bit hard to grok). It would help to have early communication about fixes you have decided against so we can argue their merits and so we don't assume you are planning to pick them up. Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
