[RFC|Merged] Require PHP 5.3

[Erik Frèrejean]

this is simply unacceptable. And I will not accept it.

I find it quite unacceptable that in the middle of the development of a version the requirements are bumped without any true benefits at this point.

That is just wrong. There are very clear benefits which have been outlined in the first post.

No, the first post just states some potential benefits for this switch (and I don't argue those), it however doesn't outlines how 3.1 will benefit of this (or is Doctrine at this point being considered for 3.1?). The RFC doesn't convince me that this change/limitation on this point bring anything crucial to 3.1 besides

A large part of our user base is on PHP 5.2 hosting

breaking the update path for this part. Therefore I see reasons for raising this requirement for 3.2, but not for 3.1.

[A_Jelly_Doughnut]

TL;DR:
Bumping the version requirement is a fine thing to do, but trying to morph phpBB3 into some "maintainable" structure is just a bad idea, and without utilizing the features of 5.3 the requirements bump is silly. I'd counterpropose my suggestion, now at least a year old, to ditch 3.x and just do phpBB4 since there's actually some enthusiasm around that idea.

====

Use third party libraries such as Symfony2 components, Doctrine2 DBAL, Assetic to replace parts of our legacy code base

I can't think of any good reason to do this.

Use Symfony2 EventDispatcher instead of copy-paste maintaining the code base (see this PR)

I'm not sure I follow the logical path in this bullet.

All MODs can potentially benefit from the same

All MODs can already benefit from features in newer versions of PHP by simply declaring their version requirement.

- We gradually add more use of PHP 5.3 features in minor releases
- Possibly get more collaboration and help to fix our dated code base

Skeptical of either one of these ever happening.

Adopt standard PSR-0 autoloading in the future

Yawn.

Right now phpBB4 is not really happening. The way I see it, this move may allow us to do what drupal is doing right now. Slowly adopting third party components and making their code base maintainable.

phpBB4 isn't happening because phpBB can't get a minor feature release out the door. Arbitrarily replacing code that works well and wasn't going to be changed anyway with a Symfony component (DBAL) is going to chew hundreds of man-hours that could be spent on the features in a feature release

I was hoping I wouldn't have to argue about that point, but I guess I was optimistic.

The hosts don't upgrade because the apps run on low versions. The PHP projects don't upgrade because the hosts don't support new PHP versions. We cannot wait for them forever. There are enough 5.3 hosts to migrate to. The irony of the situation is that they could upgrade just fine, PHP is very backward-compatible. At some point we have to push them, this is simply unacceptable. And I will not accept it.

Can I get a R'amen?

In particular the implentation of hooks would benefit from this significantly. It's obvious that we screwed up any release cycle we originally had, so reevaluating such decisions now makes a lot of sense. We should add a warning like the 5.2 one to the next 3.0 release, and quickly communicate publically, that we will no longer support hosts that run extremely outdated software. Deciding to move 3.1 into stand still because some plans failed is the worst thing we can do now.

The version number bump is a red herring in this argument.

No, the first post just states some potential benefits for this switch [snip], it however doesn't outlines how 3.1 will benefit of this (or is Doctrine at this point being considered for 3.1?). The RFC doesn't convince me that this change/limitation on this point bring anything crucial to 3.1 besides

+1, except for the snipped part, because I do argue several of the proposed "benefits."

[igorw]

You kinda have a point, just starting on 4.x would be the proper way to do all of those things I mentioned. But throwing away 3.1 at this point would be kind of stupid. There's not that much missing and anything that could add traction to completing the last few things that do is a good idea imo.

[DavidIQ]

If there is no real benefit to be had in 3.1 then what's the point in doing this for that version? I don't see anything regarding having to use 5.3 that is holding back 3.1. There are many other things holding the release of 3.1 and this is likely not on that list. What exactly in 3.1 will require PHP 5.3 anyways?

[naderman]

The way I see this is the following: We want to finish 3.1 as soon as possible. Extensions need to be finished to release 3.1. Extensions would be easier and quicker to implement fully if we could use third party components for them. Third party components we would like to use for extensions require PHP 5.3. So let's just require PHP 5.3, to get 3.1 done already, so we can move on.

I certainly disagree with replacing any currently working components, just for the sake of using external ones in 3.1. We should raise the PHP requirement, soleley to speed up the finishing of 3.1.

[DavidIQ]

I certainly disagree with replacing any currently working components, just for the sake of using external ones in 3.1. We should raise the PHP requirement, soleley to speed up the finishing of 3.1.

If that's the case then fine. Raise it and get the release of 3.1 done. I was under the impression that Oleg was working on extensions and he ran into some issues so is the solution to use third party components for the extensions system?

[Jacob]

The way I see this is the following: We want to finish 3.1 as soon as possible. Extensions need to be finished to release 3.1. Extensions would be easier and quicker to implement fully if we could use third party components for them. Third party components we would like to use for extensions require PHP 5.3. So let's just require PHP 5.3, to get 3.1 done already, so we can move on.

+1

[Oleg]

If that's the case then fine. Raise it and get the release of 3.1 done. I was under the impression that Oleg was working on extensions and he ran into some issues so is the solution to use third party components for the extensions system?

The hold up is not so much a specific version of php as how php approaches things in general.

With that said, if we use php 5.3 we can possibly speed up/improve some stuff. We could use event dispatcher verbatim and I think a dependency injection container along with an asset management contraption would be handy as well.

I will repeat myself since the following is important:

Which distributions ship which versions of php?

I am surprised that no one seemingly cares to check what versions of php debian and rhel/centos ship these days.

[igorw]

I haven't forgotten about your question.

Latest stable versions:

Centos: PHP 5.3.3
Debian: PHP 5.3.3
Ubuntu: PHP 5.3.6
RedHat: PHP 5.3.3
Fedora: PHP 5.3.8

For more, see http://distrowatch.com/table.php?distribution=<distroname>

[Oleg]

If that is the case it seems perfectly ok to me to require 5.3. Any hosts still using 5.2 must either compile it themselves or use unofficial packages; in either case it is legitimate to ask them to provide 5.3.