Bump minimum version of php required to 5.3.10

Include distro PHP versions

As much as I favor stronger hashing, I think that' no longer one of the weakest links in our security chain. At the least, it would seem hard to justify increasing the requirements for core on this basis alone?

We just found that https://bugs.php.net/bug.php?id=43200 was fixed in 5.3.9 and that caused problems in #1682778: Unify DataStructureInterface and PropertyItemInterface getters. That is a worthy bugfix to rely on.

Looking at the table above FreeBSD 9.0 would be a problem but 9.1 is out http://www.freebsd.org/releases/9.1R/schedule.html on Oct 24.

And, this came up because we are eyeing the condition unification and EFQ conditions compared to DBNTG conditions have an optional argument and so that would require 5.3.9 no doubt.

It looks like we at least have to bump to 5.3.6 due to:
#1333730: [Meta] PHP DOM (libxml2) misinterprets HTML5

The $node parameter for DOMDocument::saveHTML() was added in PHP 5.3.6.

From the opening table it's clear to me that once we bump from 5.3.5 there's little point in stopping below 5.3.10 and there's next to zero chance of going above 5.3.10 due to Ubuntu 12.04 only supporting that. Moving to catch to get a tentative date, there's no doubt now that we want this to happen.

I'm still running 5.3.6, so my current answer has to be 'some time after I get around to updating the distro on my laptop' :P

With at least one change in PHP requirements, we set a date, but committed patches that created a soft dependency (i.e. notices/warnings in Field UI) beforehand, I'm not opposed to that as long as the test bots work and there's a notice out. That way people have time to update before they're not able to install at all, but it also doesn't hold up bug fixes that require the higher version.

Do we have any idea when Centos and RHEL will catch up?

Note that I currently do not see a way to fix #1333730: [Meta] PHP DOM (libxml2) misinterprets HTML5 without bumping the PHP requirement to >= 5.3.6.

The only viable alternative for that bug would seem to be to replace the entire DOM parsing with a user-space library (e.g., html5lib), but the existing libraries are not maintained very well, so that would most likely result in other side-effects/regressions.

The next major release of Red Hat Enterprise Linux (RHEL), version 7, is targeted for release in the second half of 2013

as for Debian...

6.x (Squeeze), current:
php 5.3.3-7+squeeze14

7.x (Wheezy), TBA, probably 2013:
php 5.4.4-9

PHP 5.3.9 adds a parameter to http://docs.php.net/manual/da/function.is-subclass-of.php that seems to be affecting autoloading.

OK, this is definitely we can not release without this material now.

interface A {
  function test();
}
interface B extends A {
  function test();
}

This is the simplest case of https://bugs.php.net/bug.php?id=43200 . Maybe you want to tweak the return value, you want to add an optional argument, all those won't fly.

How about week commencing 1st March - then we can announce it now to give people to upgrade their environments if they're behind.

If there's a specific issue this one blocks please link to it from here though.

#1854708: EntityQuery aggregation support is not quite blocked but it can't document the different result set formats until this is in. So dependent but not blocked, the code works, the doxygen doesn't.

Related issue for testbot queue: #1907678: Bump PHP version to 5.3.10.

We'll target having all bots updated before the suggested March 1st deadline.

Updated issue summary.

Updated issue summary.

Updated issue summary.

FWIW, Drupal 8 will be released after the php 5.3.x branch has entered its end of life cycle (starting March 2013).

http://php.net/archive/2012.php#id2012-12-20-1

rickmanelius: that was covered for a bit in #1498574-30: [policy, no patch] Require PHP 5.4 and on before it was won'tfixed. :/

We need to consider what versions are shipped in various OS and what shared hosts support (it is not impossible that Drupal 9 won't support shared hosts but that's a monumental decision to make). As we know, the PHP team has zero connection with reality as proven recently again (and again) so their policy plays no role in this decision.

I'm all for this. Current 5.3.x branch is at 5.3.21 and a lot are already using 5.4 so upping to 5.3.10 is no biggy IMHO.

Just a sampling of hosts I have sites on:
A2Hosting dedicated 5.2.6 (must not break D6, otherwise I can upgrade anytime) switching to D7 in next few months.
A2Hosting shared 5.3.18 use for testing all - D7 - clearly ok
Webhostingbuzz 5.2.17 small production sites mix of D5, D6 and D7 (and one 4.7) - I don't know when they will upgrade
Drupal Gardens 5.2.4-2ubuntu5.26 (my usage is trivial - but suspect others depend on this)
My laptop - Windows, runs D8 several months old, easily upgraded as no dependence on anything.

@yktdan I don't think your problem is 5.3.10 per-se but rather 5.3.0 :)

If that's the highest you'll go. As chx points out

From the opening table it's clear to me that once we bump from 5.3.5 there's little point in stopping below 5.3.10 and there's next to zero chance of going above 5.3.10 due to Ubuntu 12.04

So am I to understand that Ubuntu controls Drupal? Why not use 5.13 so that it might spur some action? Ah, the unseen power of Drupal. What I love the most is discovering the power that I did not know it had, and then making use of that power.

We are not talking children's toys here, you all are leading the way in your efforts, but you might be under estimating the power you have to make a difference. Legacy systems support? Well, I guess then we should all try to make sure Drupal 7 is heaven for them. Drupal 8 needs to get with the times, as so should the rest of them. You will get drag from them of course, which in turn drags Drupal.

Still worried about market penetration?

> So am I to understand that Ubuntu controls Drupal?

Is that a relevant question? The hard requirement we have is PHP 5.3.9 (5.3.6 was saveHTML, 5.3.7 blowfish, 5.3.9 the abstract bug). Beyond 5.3.9 we have no hard requirements but we want to go as high as possible just to enjoy more bugfixes. But, we want a version that is widespread. 5.3.10 happens to be in Ubuntu LTS AND the last dotdeb for Debian oldstable AND the one shipped with the latest OpenBSD. That's what makes 5.3.10 a great candidate.

@chx, yes it is, and I'll take that answer as a yes.

Beyond 5.3.9 we have no hard requirements but we want to go as high as possible just to enjoy more bugfixes. But, we want a version that is widespread. 5.3.10

Please forgive my ignorance, but the latest OpenBSD release I see is 5.2 Released Nov 1, 2012 with PHP 5.2.17 AND 5.3.14.

You asked for feedback, and so I'm giving it. With no hard requirements, perhaps placing such a requirement on a yet to be released product does have its limitations? Obviously Drupal 8 needs to ship with PHP 5.3.13 AND PHP 5.4. :)

Obviously? Does not seem too obvious to me? Anyways the feedback we are looking for is whether 5.3.10 is going to cause problems or not, not trying to find even higher versions. Even higher version, unless we have a similarly pressing need as the three listed in the op is straight out. And, PHP 5.4 is absolutely out unless you can show us research showing widespread support (for eg hostgator has no support, site5 has partial support, bluehost is ready) AND a strong need. From what I've seen 5.4 features are nice but not mandatory. Care to link the issues you worked on and was hindered by the lack of PHP 5.4 features?

So to cut the chase, here are the kind of feedback we are looking for:

1. I am working on X and I need PHP version Y for it
2. PHP 5.3.10 is not working because...

Everyone else is encouraged to think hard on the size and reach of the Drupal ecosystem.

Collecting from my client's site:
Godaddy: 5.3.14+
Mediatemple: 5.3.15+
Hostgator: 5.3.15+

From above comments:
bluehost 5.3 ~ 5.4
site5 5.3 ~ 5.4
A2Hosting 5.3.18+

My research:
CPanel: 5.3.21+
Lunarpages 5.3.16+

Where would I begin? Why was PHP 5.4 written in the first place? The only requirements I have are those that you place, and it was stated that it was pretty much set in stone.

Maybe it is not as clear and it is not as obvious that it is in how you look at it. Really it should be PHP 5.3.15, and with 5.4 it's a "won't fix" issue. Isn't there already a PHP 5.5 version released?

PHP is "PHP," and I'm honestly trying to not offend any of the great people or the great work that they have done, but when I look at the grand scheme of things--with regards to PHP I'd say that you'd rather want to be associated with the higher end of PHP.

I'm still not sure that you've convinced me it should be PHP 5.3.10. The feedback from me is please get with the times. Are you serious about the links, because I believe one of us might have lost sight on what the term "hindered" means?

I understand the issue at hand, but I still think the answer is higher. Thank you all for at least hearing me out. I don't have quite the investment into this as some of you, so it is easier for me to play with ideas, but I would like to think that I'm trying to help out.

Topcheese:

In general, you want to be as inclusive as possible while still meeting all of your goals.

The minimum software requirements are a tug-of-war between "what will work" and "what does everything you need". The current discussion has a lot to do with bugs that were fixed as of 5.3.10, and that's currently targeted as the minimum version that will do everything Drupal needs. If the *only* benefit is "being newer", then that is no benefit at all.

The PHP4 -> PHP5 update was driven by the fact that PHP4 was going EOL, so "being newer" had a reasonable argument. However, other arguments are driven by things like 3 year release cycles on major Linux distributions. So "being newer" is a hindrance when using some of those OSes. That pushes the tug of war in the other direction.

So in my estimation "get with the times" is a difficult argument. Are we talking something that is potentially dangerously old (like PHP 4 was?) Are we talking something so new that major enterprise distros won't even have it when Drupal 8 is released? Both are valid points. Any minimum that is chosen is what Drupal will be stuck with for the next 3 years. There must be a valid reason for the actual version picked, IMO. Every time we've had this discussion, we've always settled on a break point decided by features offered or bugs fixed. And I think those are excellent arguments, and we should confine the arguments to those parameters.

Thanks merlinofchaos and chx for your time and effort. If what you say has worked out for you in the past, then who am I to say change it, as it seems to be working out for you. There is never an easy answer, but I do find it a little unsettling settling for the minimum instead of reaching for the maximum.

I appear to be hindering this process, so I will bow out now and try to catch you all on hopefully Drupal 9.

Edit: I just wanted to be clear that I don't have any issues or any problems, and that I realized my mistake. While I'm here I'd like to note that I'm really excited and that I'm really looking forward to D8. Time and time again, you all prove at least to me why you are some of the best around.

It is really quite understandable your response when someone pushes you to do a bit more, when already what you've done is impressive enough. I'm not trying to look a gift horse in the mouth, and what you all provide for free is beyond measure.

How about if I just try again to leave it at thanks!

I think most guys in this thread wants to use PHP5.5 but no one killing his business and the community in this way. For most small potatoes, we have no powers to ask customers use a new hosting. Even said minimum version is PHP5.3.5, I have to ask my customers hosting account before coding (or discuss the site specs). It will kill Drupal & Drupal developer's life time.

Use PHP5.6 in your own module, no problem, no conflicts.

see other CMS:
http://www.joomla.org/about-joomla/technical-requirements.html
http://wordpress.org/about/requirements/

By merlinofchaos' post we should pick PHP 5.3.9 however I would still go with 5.3.10 as the only difference is a security bugfix and they were released not a month apart and there is no distro that picked 5.3.9. Truly the only choice is between 5.3.9 and 5.3.10.

As for later versions, let me quote a very timely post by zeev about the now yearly released PHP 5.X versions:

there's next to nobody actually interested in consuming those releases

. Drupal core can not afford to try, either. We will have enough problems with the hosting requirements of Drupal 8 anyways.

@droplet, I really feel funny now, but I just knew it in my heart that Drupal was better than that. Thanks for the information.

@chx, very interesting indeed, thanks. I don't know what Drupal core can afford, but as long as it can pay the price when the time comes, then I think we're good.

+1

I'm fine with 5.3.10, too.

#12 would be indeed a big help documenting interfaces, I ran into this already with entity field interfaces extending typed data interfaces.

Updated issue summary.

Zend Server 5.3 is 5.3.14 and then moved to 5.4

Missed a spot :) The patch won't install on the testbots until we upgrade them to 5.3.10 as well.

Debian looks ready for a middle of the year release.... http://bugs.debian.org/release-critical/ (green line goes to zero) So this looks OK. Have to get my vms upgraded :)

#39: 1800122-39.patch queued for re-testing.

Testbot 654 is now running 5.3.10, so wanted to give this a shot on it.

Failure looks like an APC issue ... manually re-queued, and is currently past the installation phase and running assertions.

It looks to me like all the concerns around this have been addressed, and there's plenty of buy-in. And the bots are ready! So I think this is RTBC.

So, we missed March 1, but how about a week starting tomorrow, and we make a g.d.o post then if the maintainers have signed off?

Okay, I fail at reading:

Testbot 654 is now running 5.3.10, so wanted to give this a shot on it.

So the other bots still need to be upgraded?

It's trivial to update the other testbots. Was just waiting for problem reports with 654. Seems like we had some immediate issues.

All bots should now be updated.

I'm fine with 5.3.10.

Let's schedule the commit for March 15, then? If that's alright with everyone I'll post the announcement.

http://groups.drupal.org/node/287133

Windows WAMPserver 2.2e using PHP 5.3.13 (which uses PCRE 8.2) may experience pain. I certainly did:
#1917530: drupal_parse_info_format crashes with PCRE 8.12

Ironically, we JUST killed that function, I believe: #1793074: Convert .info files to YAML

Doing something with the title so I quit seeing it at the top of my commit list and freaking out. :D

Committed to 8.x. Thanks.

We also need to update http://drupal.org/node/1800122 (Both the version number and any relevant details, I think.)

Actually, looking at the existing change notice, I just increased the version number there. Sorry for noise. :)

There is no xampp version with 5.3.10... so I'm out. Latest 5.3 is 5.3.8

@hass:

I'm using wamp instead, it works pretty well: http://www.wampserver.com

you can use 5.4..it doesnt need to be exactly 5.3.10. just the minimum
i see http://www.apachefriends.org/en/xampp-windows.html has 5.4.7

Is this also needed for update.php or not ? Filed at #1949564: Bump PHP in update.php and install.php to 5.3.10

That's nice.

I can run the about-to-release Joomla and latest Wordpress on my CentOS6 server, but not D8.

Please keep in mind that we're *at least* a couple of months away until release..

Code freeze for Drupal 8 is not until July 1. 8.0 is not likely to be released until at least the fall.

So there's lots of time for upgrades yet. :)

Have you ever heard that hosters are not providing images that are up to date? I know that server4you and others in germany are often 2 years behind. Additional suse often does not provide updated packages. S4Y has provided default vserver images that suse itself has no longer supported for about 2 years. They are mostly 1year behind on root servers, too. This hosters are no exception - this is normal. This will not allow the masses to run D8.

This will not allow the masses to run D8.

or it will force the mass of the hosts to upgrade their freaking old servers

That's only a dream.

#67 ++1

If masses start to migrate away from their hosters to other ones that do provide updated images, then I'm pretty sure the hosters will be forced to upgrade. That is if they want their customers back.

I would not change my hoster only for Drupal 8, but I could be a minority. The other hosters are no better.

Just to update on #16, PHP 5.3's end of life was announced in February, but it has now been redefined to be 1 year after PHP 5.5 is released. PHP 5.5 just entered its second beta, so the final countdown to PHP 5.3 EOL won't happen for a few more months.

Two years behind, that's fine then two years after 5.3.10 came out, by 2014 february everyone will be up to 5.3.10. I am fine with that. With a fall release, that means even behind hosts will be able to run Drupal 8.1 if not 8.0. Perfect. Prepare your site upgrade with D8 on your devsite, push to prod in February? I am fine with that schedule.

39: 1800122-39.patch queued for re-testing.

Restoring status.