Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51191
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain metux.de from 82.165.128.25 cause and error)
Date: Mon, 3 Jan 2011 02:14:42 +0100
To: internals@lists.php.net
Message-ID: <20110103011442.GC27395@nibiru.local>
Reply-To: weigelt@metux.de
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4D1E48AB.6070601@sugarcrm.com>
User-Agent: Mutt/1.4.1i
Subject: Re: [PHP-DEV] [RFC] Release Process
From: weigelt@metux.de (Enrico Weigelt)

* 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) ?

> >Things like certain superglobals or calltime-reference passing
> >should neither disappear or suddenly produce warnings within
> >the stable line. The whole idea of depcreation warnings which
> 
> What you call "stable line" anyway? 

The line of stable releases, those which are meant to go in production.

> call_time_reference was deprecated since forever, and so was 
> register_globals.

Still many code relies on that. Probably not very fine concepts from
language design view, but still quite useful. If it's so bad, it
should have been gone since 5.0.

> It's not a new thing even with 5.3 - which is a major 
> version, certainly not in a subminor version.

Next major would be 6.x
 

cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------