It is absolutely related to how the PHP project approaches things. As a project we have always valued backwards compatibility and migration path. That focus and approach is one of the reasons why PHP is so pervasive. It is sometimes more fun to break (fix) everything but the reality is that while it may feel better it ultimately can have a significantly negative impact on PHP pervasiveness and success.
Generally speaking we've done a good job in balancing the two and phasing out functionality over time in a responsible way. Like any project, we've also had our missteps on that front which has made migration a bit more painful than it needed to be. Andi >-----Original Message----- >From: Andrew Faulds [mailto:ajf...@googlemail.com] >Sent: Friday, July 20, 2012 5:20 AM >To: Lester Caine >Cc: internals@lists.php.net >Subject: Re: [PHP-DEV] 6.0 And Moving Forward > >Whilst I feel some sympathy for you, I must ask if it is really the PHP project >to blame if your hosts use old PHP versions? >On Jul 20, 2012 12:50 PM, "Lester Caine" <les...@lsces.co.uk> wrote: > >> Daniel Macedo wrote: >> >>> >One little change in PHP5.3.10 or so wiped out a whole block of >>> >mine, and >>>> >the fix involved a re-writing all the <?= code across many pages. >>>> >Simply because the ISP would not switch back on short tag. >>>> >>> Did you really go through all code manually to change the short tags? >>> You should be smarter than that: >>> https://github.com/danorton/**php_replace_short_tags/<https://github. >>> com/danorton/php_replace_short_tags/> >>> >> >> If I had easy access to every FTP server and local copies of the code >> bases in each, but we still have not rationalised what we inherited >> structure wise, and the update to PHP5.3 had not even been advised for >> those hosting packages! I think it was a mistake and unfortunate that >> the version they picked had the short_tag regression. >> >> But I want to get these sites BACK to '<?=' format as well since >> '<?php echo' is simply wrong for the style of site and framework that they >use. >> I'd been tidying them up to be consistent before they blew up. >> >> One of the reasons major versions are introduced is BC breaks, those >>> don't come around frequently nor are introduced lightly, and you >>> still go through the E_DEPRECATED > .ini setting > disabled > >>> optional extension, for a safe cycle. >>> >>> I like to think we, as smart developers, would like to see complexity >>> reduced, even if we need to input a few man-hours into adapting the >>> old surviving masterpieces. >>> >> >> I've spent many DAYS on the 'strict' updates to other peoples >> masterpieces So that argument is my main objection to many of these >> 'complexity reductions' as the changes I am making add nothing to the >> functionality of these sites. >> >> The MAIN problem here is that ISP's do not update supplied versions of >> PHP even with security fixes, simply because that cause them more >problems. >> Many of the hosted sites I still need to move over are still on PHP5.2.? >> and dropping them onto a PHP5.4 machine even with all the ini settings >> correct simply does not work because they need bringing up to date to >> PHP5.3 first. I'm dragging my feet moving some 100 sites off 5.2 >> simply because I don't know what problems it's going to cause :( >> >> The stepping stone approach being pushed for these sorts of changes >> only works if everybody is following on the same stone. I bet 75% of >> sites are still on 5.2 and that moving them up to 5.4 simply would not work >cleanly? >> At least every one needs testing before moving them ... and that takes >> time ... >> >> -- >> Lester Caine - G8HFL >> ----------------------------- >> Contact - >> http://lsces.co.uk/wiki/?page=**contact<http://lsces.co.uk/wiki/?page= >> contact> L.S.Caine Electronic Services - http://lsces.co.uk >> EnquirySolve - http://enquirysolve.com/ Model Engineers Digital >> Workshop - http://medw.co.uk Rainbow Digital Media - >> http://rainbowdigitalmedia.co.**uk<http://rainbowdigitalmedia.co.uk> >> >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, >> visit: http://www.php.net/unsub.php >> >>
