"Ralf Lang" wrote in message news:54beb145.7030...@b1-systems.de...
#1 and #2 may be considered to be genuine improvements by the user
community, but #3 most certainly will not. It does not matter how you
try to dress it up, forcing your end users to jump through hoops before
they can upgrade is a customer relations disaster.
PHP and other scripting languages have done it before. They will do it
again.
That's precisely the point I am trying to make. Too many frivolous BC breaks
cause more problems than they fix.
From time to time, major release really means some rare cases won't work
as before and require manual intervention to make work again.
It's not php-exclusive.
Hell, even in the linux kernel, drivers and infrastructure from bottom
to top we see it every day. Design changes, things break, fix or perish.
Those BC breaks were necessary and not frivolous.
1995 HTML will probably not look exactly as intended when browsed with
today's browsers.
But at least they will still appear and not simply produce a blank page.
Chances are, even your 20 year old C or C++ code won't compile on the
latest gcc without some trivial changes or some additional compile
options and even if it does, it will violate some widely accepted
policy. In distribution packaging, we face the latter more often than
you think. This is especially true with feature-complete software
dinosaurs.
Trivial changes because of necessary BC breaks I can live with, but
monumental changes due to frivolous BC breaks just make me mad!
Software needs maint. to keep it alive in an ever changing environment
of hardware, OS, platform libraries etc. If PHP decides to drop PHP4
constructors in PHP7, which is 2 and a half major releases later,
The number of releases later is irrelevant. PHP 4 constructors have NEVER
been marked as deprecated, therefore they are still fully supported and not
obsolete.
And I still say that their removal is entirely frivolous and unnecessary.
then
you can run your older PHP, you can add support via an extension or fork
or you can do trivial changes to your libraries.
Each has its own costs. Doing nothing also has costs.
A minor cost to the core developers is far better than a major cost to the
240 million websites out there in userland.
I have to maintain some customer apps on a PHP4-based framework
(version). It hasn't been fun to keep it working on PHP5.3++ and it
won't be fun on PHP7 either. It's just the way it is. I think the
customer will be charged a lot of support hours but he will get a much
better product.
How can the move from the old to the new constructors add any value to
product? It certainly would not make it run faster or produce better
results.
In theory, I could just run older PHP releases but in practice, I wont.
I also want to be able to run the latest PHP release so that I can gain
access to all those bug fixes, but a constant flow of frivolous BC breaks
makes this very difficult.
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
