Hi!
IIRC many deprecation warnings, which totally broke the output.
Err, you actually output the warnings in your output? In production?!
Please tell me you turned it off now, at least - it would make
deprecation warning doubly beneficial. I'd even consider inserting
couple of random ones just to make people turn off display_errors in
production.
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.
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. 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.
Anyway, last such change I can recall was in 5.3.0.
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? E_DEPRECATED was added in 5.3.0, and
most deprecations were introduced or converted from warnings then. The
only change I see related to deprecation post 5.3.0 is this:
. Changed deprecated ini options on startup from E_WARNING to
E_DEPRECATED.
Which changes already existing warning to lower level.
call_time_reference was deprecated since forever, and so was
register_globals. It's not a new thing even with 5.3 - which is a major
version, certainly not in a subminor version.
I really can understand the idea of these warnings, as well as
removing things like superglobals, from development perspective.
But they better belong into an additional instrumentation system
which does not affect the behaviour of the running applications
(eg. send these warnings to syslog instead of stdout, unless
_explicitly_ asked to do otherwise).
PHP goes at *extraordinary* length to keep BC - including keeping with
some stuff that everybody hates and wishes it was different, but because
of BC is not being changed. 5.3.0 did some minor changes - that's what
the x.0 versions are for. If you discover some BC breaks in non x.0
version - you should complain, as they are not allowed except if they
fix a major bug or there's another very very good reason. However so far
I don't see much basis to complain about 5.3.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
