Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25990
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain emini.dk designates 192.38.9.232 as permitted sender)
Message-ID: <45284BE0.8000102@emini.dk>
Date: Sun, 08 Oct 2006 02:52:48 +0200
Organization: Emini A/S
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Antony Dovgal <antony@zend.com>
Cc: Rasmus Lerdorf <rasmus@lerdorf.com>,
	Ilia Alshanetsky <ilia@prohost.org>,
	PHP Internals List <internals@lists.php.net>
References: <4526E304.50701@emini.dk> <4526E5F6.7040506@lerdorf.com> <452845A9.1040609@emini.dk> <45284A35.6020000@zend.com>
In-Reply-To: <45284A35.6020000@zend.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Release php-5.2.0RC6
From: edink@emini.dk (Edin Kadribasic)

Antony Dovgal wrote:

> I tend to disagree with you here, Edin.
> Releasing one RC just after another - _that_ would be bad management.
> RCs are RCs, if something is broken in one of them, let's wait for the 
> next one and see if it ok.
> 
> Also, I don't like the rush in the release management which to appears 
> from time to time, but this time (I mean 5.2) something (or someone) has 
> changed and I really like how it goes, so let's make it as stable as we 
> can and push it out of the door without any hurry.

I believe that there is very little sense in making release candidates 
and continue on committing patches, and in case of PHP major feature 
changes while in the release process. I guess changes to the code should 
be kept to minimum and reserved for critical bug fixes. Otherwise there 
is no telling what broke since the last release candidate and they 
become pointless.

Edin