According to our release matrix, the minimum requirement for Flow 7.3 is, at the moment, PHP 7.3.
PHP 7.3 reached its end of life on December 6th, 2021 and there are no security updates published anymore. Therefore, it is more and more irresponsible to use PHP 7.3 in production.
On the other hand, there are missing features and a few bugs we’d like to fix to make Flow 7.3 fully compatible with PHP 7.4 (for example, typed class properties).
Now the problem is, that my solution for this requires a version of a third-party package (Laminas Code Generator) which is incompatible with PHP 7.3. And I need to to a lot of code-bending to let functional tests pass with PHP 7.3 but also with PHP 8.1. This is a lot of work and, in my opinion, creates a mess through a lot of if (version_compare(PHP_VERSION …) code in the core.
My suggestion: Let’s drop support for PHP 7.3 in upcoming releases of Flow 7.3 and raise the requirement to PHP 7.4.
That way, people who still use Neos with PHP 7.3 will just need to get on with Flow 7.3.1. That works, but they don’t get further Flow updates – as they don’t get further PHP updates.
If we would continue to support PHP 7.3, what would happen is that fixes and new features which require PHP 7.4 would not end up in the Flow 7.3 branch anymore, but are exclusively developed for Flow 8. That would be a pity for everyone using Flow 7.3.
After a short discussion at Flownative about this, in which I was originally opposed, I think this is the right step. We can prevent installation of those bugfix versions via platform requirement, and as long as that works I am fine as you cannot accidentally create a broken change (unless you use composer with a higher php version than you actually run on but then you are doomed anyways).
Sounds reasonable in terms of effort and time spent. But you mention Flow 7.4, was that just a typo, or is then Flow 7.4 meant to be the new LTS version of the 7.x line?
Sorry, yes, typo, too many numbers. I meant Flow 7.3 (LTS).
Thinking more about it, we could also make this a general rule, which we publish on our Release Process page:
For each patch-level Flow and Neos release we check if the minimal required PHP version is still supported. In case PHP security support has ended (see supported PHP versions), the minimal required version is raised to the next PHP version with security support on the next Flow / Neos (patch-level) release.
What I don’t understand yet is why it is incompatible with 7.3 - Laminas is already a transient dependency, so the version we have installed on a 7.3 setup should be compatible with it. From what I could see on a quick glance, the test failures on 7.3 seem to suggest some subtle code difference. I’ll take a look later today.
make this a general rule
Not so fond of this tbh - I think raising the platform requirement in a patch level release is a bad practice. All it does is cut people off from bugfixes on installations that were promised to work on their current platform initially. If upgrading PHP versions would be painless every time, I’d maybe be fine with it, but that’s just realistically not the case. Often enough it’s quite some pain and time invested to pull it off.
I’m all for increasing the minimum PHP version in minor/major versions vigorously and I’d even have made the case to make Flow 8 require PHP 8 minimum, but there’s a few technical reasons to not do it yet and still support 7.4 for at least another minor version. So incentivicing platform updates with Framework features I consider a good thing, but using bugfixes for that is IMO a dark pattern.
This policy will be followed on a best-effort basis. In extreme cases it may not be possible to support a release for the planned lifetime; for example if a serious bug is found that cannot be resolved in a given major version without significant risk to the stability of the code or loss of compatibility. In such cases, early retirement of a version may be required.
That being said, if someone is on PHP 7.3 and uses Flow/Neos 7.x, that seems contradicting. The most recent Flow/Neos on a PHP version that is officially dead.
Also, keep in mind that their setup will continue to work, but just like there are no more fixes for “their PHP”, there will be no more fixes in Flow/Neos accessible to them.
Upgrading from PHP 7.3 to PHP 7.4 is easy, I have not had an issues with that.
So incentivicing platform updates with Framework features I consider a good thing, but using bugfixes for that is IMO a dark pattern.
While i like that we move to 8.0 for the next major i do not like to raise php requirements in a minor update. I agree that php 7.3 is out of service but there are servers and customers that run such versions much longer like some payed LTS versions of linux.
It would not be nice to effectively cut those of from security updates, especially as those customers likely payed extra (but not us) to have a “very secure” os. It would also be a very bad marketing idea. I personally would avoid software with such release policy.
Even if using plain PHP is not responsible, distributors take great efforts to backport security relevant discoveries to their maintained and delivered versions. Changing the requirement in a Minor release cuts companies off support of their installed versions and might cost trust in us as being a responsible maintainer.
Would it be more acceptable, if users of Flow 7.3 would be cut off from better PHP 7.4 compatibility? Because I have the impression that making a feature / fix compatible with all PHP versions from 7.3 to 8.1 is not always feasible and a lot of extra work. I could imagine that devs avoid that hassle and rather not create fixes for Flow 7.3 then.
Also consider that includes all Neos and Flow packages / plugins. I will probably not be able to provide PHP 7.3 compatible versions of all packages I maintain.
Hm… why not… add in an extraordinary Neos 7.4 version? Sounds good. The only thing is it makes it look as we try to synchronize Neos versions to PHP versions.
That is right but we can announce that in the release Notes that 8.0 will be the minimal version for the 8.0 branch up to 8.3 LTE. So this alignment of version numbers will not last long.
I’m also in favor of having Neos 7.4 with PHP 7.4. Looking at the version matrix it looks like there was also a precedent when PHP support for a newer version was introduced with a bugfix release:
@robert i agree we should not state that 7.4 is another LTS. It would be an additional minor that replaces PHP 7.3 with 7.4 and fixes bugs we otherwise can not fix reasonably in 7.3.
That way it does not get the full support time of an LTS (2 years support +1 year security starting at the release date). Instead it gets the end of support that is defined by 7.3 trough the upmerges.
Do we want to support PHP 7.3 in future Neos / Flow patch level releases? Do we want to maintain additional branches as a compromise? Or Should we orient PHP requirements on which PHP versions are still supported?
Let’s take a decision on this. The decision covers all packages in neos/flow-development-collection/ as well as neos/neos-development-collection/.
Raise the PHP requirement to PHP 7.4 for the next Flow 7.3 and Neos 6.3 release
Start a new branch Flow 7.4 and Neos 6.4 which requires PHP 7.4 and whose support terms are the same like Flow 7.3 and Neos 6.3 respectively
Leave PHP requirements as they are and release changes which are incompatible with PHP 7.3 only in Flow 8.0.0 / Neos 7.0.0 or later
