This RFC is not controversial; it simply did not have sufficient information to make an informed decision until bantu provided it just above.imkingdavid wrote: I'm not sure why this RFC is so controversial
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.
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?imkingdavid wrote: 2. We take the time to write all functionality currently supplied by our vendors because we can't bump up one maintenance release
This is a dangerous assumption to make. Redhat for example used to ship php 5.1.6 for quite some time as I recall.imkingdavid wrote: by the time we get around to doing that, 5.3.3 will be much more common
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.imkingdavid wrote: 3. We decide to not include Events, Dependency injection, and Functional testing
Test suite is allowed more leeway as users aren't expected to need to run it on all configurations the software itself supports.