hi Jan, On Tue, Jan 29, 2013 at 3:50 AM, Jan Ehrhardt <php...@ehrhardt.nl> wrote:
> De spijker op z'n kop, as the saying over here in Amsterdam is. There > are two reasons why I try to change to PHP 5.4 once in a while: > 1. In my testing it is a little bit (10%) faster than PHP 5.3. > 2. PHP 5.3 will be out of support (even security related) much too soon. > Every time I try to upgrade to 5.4, I have to revert it because I run > into another drupal module that is not yet adapted to PHP 5.4. Two weeks > ago I was once again confronted with errors under PHP 5.4. The module, > responsible for the error: Content Access. > http://drupal.org/node/1533186 This is one of the reason why the 'new' release process RFC does not allow BC breaks. But we can't be 100% sure that we do not introduce one without you, all projects and users, doing intensive testing using your apps, modules, plugins, etc. And before the final releases, not after. Question: Did you test D7/8 and their respective plugins with php 5.5? > Zeev Suraski in php.internals (Mon, 28 Jan 2013 19:22:38 +0200): I wrote that, please either reply to one mail at a time or keep the context :) >>I think many of us are purely and simply totally out of sync with our >>users. I have no immediate solution but this is something we must solve, >>now. > Sadly enough, but true. Just read the comments by Thomas Bley, Florin > Patan and even Lester Caine in this thread. I was really appalled by the > outcome of the PHP 5.3 end-of-life vote. Reality check: Drupal6 is not > and probably never will be running smoothly under PHP 5.4. Drupal7 is > behaving better, but if somebody asks me what would be the best choice > for Drupal7 at the moment I'll advise PHP 5.3 without any hesitation. > Only concern: PHP 5.3 will be without security updates within a year and > some months. There is nothing we can do about that. Also we work closer with distributions to be sure that we are all in sync. Distributions will backport security fixes for a longer period. We can't afford to support many branches for 5-8 years per branch. That's simply not possible with our resources. However it would be nice that you keep in mind what we have done in the last couple of years, to reduce the wtf factors on update, to do more bugs fixes releases, fixed release cycle, BC policy, fixed life cycle. I am very confident that all these changes help to reduce the delay to migrate to newer versions, given that the main reason users (ISP or developers) do not update are BC issues. But that is not something we can achieve without projects support, projects like Drupal or WP. Increasing the recommended version to run your current stable releases help, a lot, instead of keep recommending 5.2 or even lower for some other projects. This is a dual side problem, one cannot blame only php.net for not doing the right things. We did mistakes, we learned from them and we changed drastically the way we work, the way we move forward. > Another point of view for US-citizens: many of our sites deal with > patient information and therefore we are bound by HIPAA-restrictions. > Quote from > http://www.hhs.gov/ocr/privacy/hipaa/understanding/srsummary.html > > |Transmission Security. A covered entity must implement technical > |security measures that guard against unauthorized access to e-PHI > |that is being transmitted over an electronic network > > Running those sites on a PHP version without security updates is > out-of-the-question. Distros offer extended long term support for this exact purpose (not specific to US). That's not something we can support, unless we create an org with full time employees doing only support. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
