Bump minimum version of php required to 5.3.5

Do we have an idea when the next versions of RHEL and Centos are due out? Presumably they'll update PHP at least one point release.

I'm absolutely fine with upping requirements for 8.x (and the specific ArrayAccess issue will be useful for a few things), the only question is whether we'll break people's development environments now as we did for a while with Ubuntu.

"Sometime in 2013" according to this article http://www.serverwatch.com/server-trends/the-future-of-red-hat-enterpris...

Tim Burke, vice-president of Linux Engineering at Red Hat, noted that key themes for RHEL 7 will include data center operational efficiency, virtualization and cloud enhancements as well as advancements in the integrated developers' tools.

"The status is we have now completed product planning, and there will be a RHEL 7 public beta in the first half of 2013," Burke said.

CentOS will follow shortly afterwards. I'm not sure of Red Hat's update cycle within a major version though.

bump-minimum-version.patch queued for re-testing.

I'd be okay with this; we CentOS users are definitely used to using different repos for things like PHP anyways, lest we be stuck 3 years behind on certain packages (I'm running a few 5.x servers with PHP 5.3.10 and the remi repo).

Based on those testbot results, I don't think this patch will be possible without upgrading all testbots to PHP 5.3.4+

Right but the testbot people #1759340: Roll and deploy 2.13 want committer approval first (obviously).

Edit: #3 seems to be it.

php version increase is something we are tracking #1759340: Roll and deploy 2.13 along with other changes to be rolled out soon.

Sorry guys for the disruption but 5.3.4 is almost nonexistent. There are no distros shipping it, there was only one change between 5.3.4 and 5.3.5 in the changelog (the famous big number crash), dotdeb only has http://archives.dotdeb.org/dists/lenny/php5/ http://archives.dotdeb.org/dists/squeeze/php5/ 5.3.5 too. So I strongly recommend going to 5.3.5 otherwise we need to roll our own deb package for the testbot.

Or perhaps go straight to 5.3.8 as the lowest common denominator? Reviewing the changelog there are quite a few useful fixes and I remember someone wanting 5.3.6 for something (perhaps the argumentless debug_backtrace?)

Per #1 Current Debian (squeeze) is 5.3.3, not 5.4. So it goes on the problem list as well.

This actually comes up because the testbots run Debian squeeze, so we'll have to use dotdeb packages or something when 5.3.4 is required.

Collision; restoring title and status

Note that by the time we ship, Debian will be at Wheezy (it's beta already) so that will cease to be a problem (it ships 5.4.4).sarge, etch, lenny and squeeze both came at roughly two year intervals, by that count wheezy should be released 2013 spring (and it's beta already).

Current Debian stable is 5.3.3 (that's what our Dev system at work has), which is my only concern. The next stable will be 5.4, which should be fine. So +1 in general, cautious on timing.

I withdraw #12 and stick with the title: FreeBSD 7.4 and 8.2 both shipped with 5.3.5. Let's go 5.3.5.

OpenBSD 5.0 was 5.3.6 and 5.1 is 5.3.10. That's fine too.

[edit: crosspost]

Not sure what is needed to move forward here, but we'd really need this to move forward on a couple topics.

"widgets as Plugins" & "move Field config to CMI / ConfigEntities" require turning $field and $instance into classed objects, and using ArrayAccess is the only way for both issues to not start with a 500k patch upfront.
And being able to use d.o testbots would also be a significant help.

[edit: and, as noted above Field API is not the only subsystem involved. ArrayAccess will be an instrumental kickstart tool for many "X as plugins" or "Y as ConfigEntity"]

I will take a look at building a testbot with higher php 5.3. If it works, we can see how we do.

Added OS to summary

OK, testing on testbot 953, which is a 5.3.5 testbot it works :-) (I forced it to retry there.)

OK, seems that everybody is in favor. The testbots are all upgraded to php 5.3.5.

Are there any current patches blocked on this?

I'd like to schedule this and announce it in g.d.o/core so that anyone on an older version of PHP has time to update, but how long it's scheduled in advance depends on the answer to the first question :p

As above I think the Field API as Plugins code is going to require either this patch or a 1MB patch file. :-) I don't know how close that is to caring though, now that testbots are upgraded.

We're good as long as the test bots run 5.3.4+. No hurry for the actual requirement bump.

added a note on 5.3.4

Looks like catch has got this one.

yched, if you start using 5.3.4 features -- that's IMO fine -- we already need to announce in case some developers use Squeeze / CentOS and we do not want them to file bug reports.

Over at #1201444: Strenghten password hashing mechanism they are suggesting PHP 5.3.7 as the minimum version. Cross-posting.

Going 5.3.10 would only burn a few *BSD systems -- and FreeBSD has their 'ports' repository which is source code based so available on every release if I understand this correctly and that is latest PHP (5.4.x). Also, FreeBSD 9.1 is already RC. OpenBSD 5.0, well, it's already not the latest OpenBSD. So, Ubuntu LTS and OS X lets us go with 5.3.10. That's the bold question: do we skip those too and go 5.4 immediately? Traits. $this binding closures. That'd be very yummy.

So, 5.4.0 or 5.3.10?

Lets not forget the thousands of shared hosts out there who are only just now getting around to 5.3.x... I think 5.4.x would be too ambitious for D8 :(

There is an existing discussion around 5.4 here for reference #1498574: [policy, no patch] Require PHP 5.4

Yeah. Likely 5.4 is too ambitious. Sad. Should I bump the title to 5.3.10?

Moving back to CNW. I'm personally happing bumping 5.3.x requirements as high as is remotely reasonable as long as we give people some warning to upgrade their dev environments etc. There's still nearly a year before the earliest likely release date so actual sites and hosting companies have ages to catch up.

We should keep 5.4 in a separate issue since that seems unlikely at the moment.

I would favor 5.3.7 or higher since that will enable us to switch to bcrypt/blowfish for password hashing, which is stronger than what we have now (a major reason is that the password stretching would be in a C loop rather than a php loop, so harder for an attacker to exploit through optimization), as well as being more standard.

5.3.10 would be fine as well, although unless we have a known requirement or bug it is perhaps unnecessary to push it higher than necessary. It's a long way off though, so we can fine tune as we go.

Also, AnnotatedClassDiscovery has a workaround for not having 5.3.6.

#1785256: Widgets as Plugins is now RTBC, and currently blocked on this.

On IRC, catch said that we could consider moving to 5.3.5 as an immediate step to make ArrayAccess uses possible, and see about larger bumps later.

So tentatively pushing back to RTBC ?

I'll let catch make this decision.

I confirmed with yched on #1785256: Widgets as Plugins that the ArrayAccess usage is primarily for backwards compatibility at the moment until all widgets are converted. That means it's at least possible for us to roll this back later if we absolutely had to for some reason - assuming we're not relying on the ArrayAccess bug fix elsewhere by that point.

So, I'm going to commit this in two weeks, then we can move this issue back to active for the 5.3.10 bump (which I'd definitely want to schedule further in advance than two weeks), and tag with revisit before release so we check the distro status closer to the time.

fix links

Cool stuff! Should we post a notice to the Core group to give devs running a D8 site a heads-up?

catch already did (see link in his post), I think.

Ahh, that was too nifty for me to catch (no pun intended). Sorry for the noise and thanks @Owen Barton.

I recommend December 1 as the 5.3.10 date.

I keep forgetting which day I said I'd commit this. It's October 1st :)

This is catch's.

Alright. Committed/pushed to 8.x.

Opened #1800122: Bump minimum version of php required to 5.3.10 to track a second bump.

I have adjusted the change notice at http://drupal.org/node/1600010 accordingly.

Posted a patch for INSTALL.txt at http://drupal.org/node/1801032

It looks like some updates to http://drupal.org/requirements are needed -- and is there any core README or other text file that needs an update besides INSTALL.txt? If so, should we set this to "needs work / needs documentation (tag)" ?

Whoever updates the Reqirements page should probably incorporate the other stuff from http://drupal.org/node/1600010 (change notice) besides just that 5.3.5 is required.

#52 thanks for pointing to docs
updated from change notice for D8

It looks like we 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.

Since there is #1800122: Bump minimum version of php required to 5.3.10 as separate issue and that one wants to bump even higher, I don't know whether it makes sense to re-open this issue or continue over there.

Webtatic is a guy in his basement; IUS repo is supported, widely-used, and well-maintained. Let's recommend IUS.

At the moment Drupal 8 requires PHP 5.4 (and we are months past whatever release date was originally assumed in these discussions) so I guess the "revisit before beta" tag here should just be removed.