Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51193
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.160.42 cause and error)
Message-ID: <4D2127E4.1050300@lerdorf.com>
Date: Sun, 02 Jan 2011 17:35:32 -0800
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: weigelt@metux.de
CC: internals@lists.php.net
References: <AANLkTi=ox5uUvEpo8ZuegpTPJLiS353Oqtud1WFGOPUT@mail.gmail.com> <1290504719.2294.251.camel@guybrush> <AANLkTi=Lqki0nY2wgKRafTBGinPZZ+VLqkHagXzyJiMq@mail.gmail.com> <AANLkTimrd_5do=3PLB4w1jBNzzO0LBY4Jvqftjqeda7X@mail.gmail.com> <20101231035937.GA18520@nibiru.local> <4D1D695C.9040400@sugarcrm.com> <20101231114927.GC18520@nibiru.local> <4D1E48AB.6070601@sugarcrm.com> <20110103011442.GC27395@nibiru.local>
In-Reply-To: <20110103011442.GC27395@nibiru.local>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Release Process
From: rasmus@lerdorf.com (Rasmus Lerdorf)

On 1/2/11 5:14 PM, Enrico Weigelt wrote:
> * Stas Malyshev <smalyshev@sugarcrm.com> wrote:
>> Hi!
>>
>>> IIRC many deprecation warnings, which totally broke the output.
>>
>> Err, you actually output the warnings in your output? In production?! 
> 
> Something seem to turn them on magically, no idea what it was.
> (perhaps the config variable name changed ? ;-o)
> 
>>> I, personally, have no time to test prereleases of dozens of
>>> packages (php is just one of dozens I'm using, not in the list
>>
>> Of course, nobody personally has any time. But PHP is a volunteer 
>> project, so if nobody has the time, nobody should complain about "php 
>> developers not caring". PHP developers are caring, but it's not humanly 
>> possible for them to foresee everything, that's why testing exists.
> 
> True. But at least we could use an development process that requires
> less testing (or automates much of it). Perhaps starting with clear
> specifications which it gets tested against.
> 
> If it was some commercial project and I was the chief architect,
> I'd require my people to first have a well-thought specification
> before starting actually implementing anything new.
> 
> I know, it's a big beaurocracy which doesn't make as much fun as
> coding, but at some point it gets necessary for stability and
> reliability.
> 
>>> IMHO there's a fundamental flaw in the development process:
>>> existing semantics in a stable line should _never_ change.
>>
>> Deprecating a function is a very minor change and doesn't change the 
>> semantics.
> 
> The fact that those warnings suddenly appeared in the output *is*
> a semantic change. I still wonder why went to stdout instead of
> syslog in the first place.
> 
>> It's a warning that semantics is going to be changed - and if 
>> it took a major version to deprecate every single thing, we'd be now 
>> somewhere at PHP 318.0. I don't think that's what you mean by stability.
> 
> Why such kind of deprecations at all ?
> Why dont such things become optional (buildtime) features that are
> enabled by default (unless some --disable-deprecated-foo given) ?

Nope, we really didn't change anything.  The simple explanation is that
you installed without or with a different php.ini from the previous
version.  If you go back and use your current php.ini config with the
version of PHP you were upgrading from you will see exactly the same
output.  Like I said, no defaults changed, no warnings were added, nor
removed.

-Rasmus