[RFC|Merged] PHP 5.3.3 or more

[Oleg]

I'm not sure why this RFC is so controversial

This RFC is not controversial; it simply did not have sufficient information to make an informed decision until bantu provided it just above.

First you (the collective everyone who needs a clarification on how dependency version bumps work) need to understand that you (any one in just described set of people) are not the only user of phpbb. Users of phpbb install it on, guess what, popular distributions. If the currently supported redhat/fedora/centos php release cannot run phpbb, a lot of phpbb's users have a big problem. Maintainers are trying to balance the needs of developers (my snazzy feature X does not work without some dependency Y) against the needs of users (I cannot use the software if it requires dependency Y).

Now it should hopefully be clear why an RFC consisting of "my snazzy feature X requires dependency Y, let's include it" is insufficient for a maintainer to make an informed decision as to whether or not dependency Y should be included, or developer should be told to make their feature X work without Y.

Therefore, the first thing you (someone proposing an RFC such as this one) do is research what the popular distributions ship. If all or most ship a version that is >= the one you want - you are done!

If some ship a version that is < the one you want, you need to research the differences between the version that is shipped and the one you want. There are some possibilities:

1. The newer version fixes serious bugs. The old version basically does not work. In this case whoever is still shipping the old version is likely to be under pressure to upgrade their version as they are shipping unusable software. Good argument to require a higher version.

2. The newer version adds a feature that can be emulated or implemented with the old version. In this case implement the feature if it is missing. No version bump is needed.

If you looked at the commit bumping the minimum version for symfony, you may have noticed that it did not start using any features of php 5.3.3. It simply noted that some stuff that was broken in earlier versions will now work correctly on all supported versions. Meaning, it may be possible to actually run the current version of symfony on php 5.3.2 with phpbb, provided the bugs don't affect us. Which is another possibility with respect to version bump - minimum version for developers using composer becomes 5.3.3 but users using pre-built packages will be able to use software on 5.3.2.

2. We take the time to write all functionality currently supplied by our vendors because we can't bump up one maintenance release

Any time we depend on third-party software we need to consider their versioning and dependency policies. At what point does symfony allow itself to bump its php version requirement?

by the time we get around to doing that, 5.3.3 will be much more common

This is a dangerous assumption to make. Redhat for example used to ship php 5.1.6 for quite some time as I recall.

3. We decide to not include Events, Dependency injection, and Functional testing

If events and functional testing, which have been in our tree for months, have required php 5.3.3 all along, there has been a serious fail somewhere. If they have not required php 5.3.3 when they were merged but do now, the question becomes how they manage to change their requirements like that under us.

Test suite is allowed more leeway as users aren't expected to need to run it on all configurations the software itself supports.

[Oleg]

I think that as we are only bringing it up 1 maintenance release it isn't a massive change and I can't really see much reason to not update the requirement.

Please see the previous post for an explanation of how dependency version bumps work. It does not matter that you are bumping one minor version or ten.

All major distributions are already shipping PHP 5.3.3 or newer in their current stable versions.

Since you appear to have posted that before bantu's post enumerating who ships what, which distributions have you checked to make this statement?

[MichaelC]

I think that as we are only bringing it up 1 maintenance release it isn't a massive change and I can't really see much reason to not update the requirement.

Please see the previous post for an explanation of how dependency version bumps work. It does not matter that you are bumping one minor version or ten.

All major distributions are already shipping PHP 5.3.3 or newer in their current stable versions.

Since you appear to have posted that before bantu's post enumerating who ships what, which distributions have you checked to make this statement?

See moderator logs, I edited my post. I based that on your announcement and originally removed that line because we didn't know yet.

I'm not sure why this RFC is so controversial

This RFC is not controversial; it simply did not have sufficient information to make an informed decision until bantu provided it just above.

First you (the collective everyone who needs a clarification on how dependency version bumps work) need to understand that you (any one in just described set of people) are not the only user of phpbb. Users of phpbb install it on, guess what, popular distributions. If the currently supported redhat/fedora/centos php release cannot run phpbb, a lot of phpbb's users have a big problem. Maintainers are trying to balance the needs of developers (my snazzy feature X does not work without some dependency Y) against the needs of users (I cannot use the software if it requires dependency Y).

Now it should hopefully be clear why an RFC consisting of "my snazzy feature X requires dependency Y, let's include it" is insufficient for a maintainer to make an informed decision as to whether or not dependency Y should be included, or developer should be told to make their feature X work without Y.

Therefore, the first thing you (someone proposing an RFC such as this one) do is research what the popular distributions ship. If all or most ship a version that is >= the one you want - you are done!

If some ship a version that is < the one you want, you need to research the differences between the version that is shipped and the one you want. There are some possibilities:

1. The newer version fixes serious bugs. The old version basically does not work. In this case whoever is still shipping the old version is likely to be under pressure to upgrade their version as they are shipping unusable software. Good argument to require a higher version.

2. The newer version adds a feature that can be emulated or implemented with the old version. In this case implement the feature if it is missing. No version bump is needed.

If you looked at the commit bumping the minimum version for symfony, you may have noticed that it did not start using any features of php 5.3.3. It simply noted that some stuff that was broken in earlier versions will now work correctly on all supported versions. Meaning, it may be possible to actually run the current version of symfony on php 5.3.2 with phpbb, provided the bugs don't affect us. Which is another possibility with respect to version bump - minimum version for developers using composer becomes 5.3.3 but users using pre-built packages will be able to use software on 5.3.2.

2. We take the time to write all functionality currently supplied by our vendors because we can't bump up one maintenance release

Any time we depend on third-party software we need to consider their versioning and dependency policies. At what point does symfony allow itself to bump its php version requirement?

by the time we get around to doing that, 5.3.3 will be much more common

This is a dangerous assumption to make. Redhat for example used to ship php 5.1.6 for quite some time as I recall.

3. We decide to not include Events, Dependency injection, and Functional testing

If events and functional testing, which have been in our tree for months, have required php 5.3.3 all along, there has been a serious fail somewhere. If they have not required php 5.3.3 when they were merged but do now, the question becomes how they manage to change their requirements like that under us.

Test suite is allowed more leeway as users aren't expected to need to run it on all configurations the software itself supports.

With regards to the version, we don't know that code hasn't been added since then so unless you plan to go through every change made since then (a few PRs get merged a day in case you interested and that commit was 6 months ago) with the knowledge of every single change that happened in 5.3.3. Plus even if we did this audit, every further symfony component we use will need this audit done again the the audit will need doing every time we update deps.

Symfony bumped up its php version in a new major version which included plenty of BC breaks (none except this affected us). https://github.com/phpbb/phpbb3/commit/ ... f2866d9c10 updated the symfony version from 2.0.0 to 2.1.0 which bumped up the php requirement and yes, it did escape our knowing and that is a failing but we shouldn't dwell on our mistakes but learn from them and move on.

To not change the version, no matter what we do, whether its your suggestion of ignoring it (requiring an audit) or changing to not use symfony 2.1 and remove functional testing (causing possible regressions and damage to the testing infrastructure we all agree needs to be improved, not having half removed).

[Oleg]

Test suite does not dictate package requirements. We can have functional tests in olympus if we want. The software itself remains usable on php 4. This may be why the change you linked to was merged - it does not affect our users.

I think you still are only seeing the developer's point of view. Did you read the huge post you quoted?

[MichaelC]

Test suite does not dictate package requirements. We can have functional tests in olympus if we want. The software itself remains usable on php 4. This may be why the change you linked to was merged - it does not affect our users.

I think you still are only seeing the developer's point of view. Did you read the huge post you quoted?

Of course. The change I linked to changed the version of the event dispatcher to 2.1, which does affect our users as you pointed out. Did you read the commit i linked too?

From the users point of view: I'd rather have a release sooner rather than later and would prefer that developers spent their time developing nice new features for me to use than spending lots of man hours doing pointless work because they can't bump up a php version requirement one maintenance release which is supported by all the majority of users who could support the previous limit.

Please, come up with a way we could not update the requirement that does not require countless amounts of work & removing functional testing or find someone that is able to/is willing to do the countless amounts of work whilst making sure it does not have any or has little consequences to phpBB development.

The reason we bumped the php minimum requirement to 5.3.2 was to save ourselves re-writing things ourselves for the same reasons. Why are those reasons suddenly invalid?

[Oleg]

The change I linked to changed the version of the event dispatcher to 2.1, which does affect our users as you pointed out.

That one can be backed out then as the previous version worked fine to my knowledge.

[Oleg]

The reason we bumped the php minimum requirement to 5.3.2 was to save ourselves re-writing things ourselves for the same reasons. Why are those reasons suddenly invalid?

They are not invalid. At the same time they do not create a "free for all".

Right now increasing minimum requirement to 5.3.3 is ok, anything higher than that is not ok.

[MichaelC]

The change I linked to changed the version of the event dispatcher to 2.1, which does affect our users as you pointed out.

That one can be backed out then as the previous version worked fine to my knowledge.

Not really we we use other 2.1 components which rely on the 2.1 event dispatcher. We'd have to move the whole lot.

Anyway, so by:

The reason we bumped the php minimum requirement to 5.3.2 was to save ourselves re-writing things ourselves for the same reasons. Why are those reasons suddenly invalid?

They are not invalid. At the same time they do not create a "free for all".

Right now increasing minimum requirement to 5.3.3 is ok, anything higher than that is not ok.

I assume you are ok with this requirement bump?

[Oleg]

That is correct.

[igorw]

So, let's do it.