Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59563
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain oracle.com designates 148.87.113.117 as permitted sender)
Message-ID: <4F8356BA.1070904@oracle.com>
Date: Mon, 09 Apr 2012 14:38:02 -0700
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Stas Malyshev <smalyshev@sugarcrm.com>
CC: PHP Internals <internals@lists.php.net>
References: <4F82878A.6030609@sugarcrm.com>
In-Reply-To: <4F82878A.6030609@sugarcrm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] release process with git
From: christopher.jones@oracle.com (Christopher Jones)



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.jones@oracle.com
Tel:  +1 650 506 8630
Blog:  http://blogs.oracle.com/opal/