RFC: Drop PHP 7.3-support in all future Flow versions

Sorry, I can’t change this poll anymore, but of course it’s supposed to be Neos 7.3 instead of 6.3 – always the corresponding Neos version for the Flow version I mentioned. :woozy_face: (thanks @Marc for the hint)

I voted for “leave PHP requirements” but I’m fine with “raise PHP requirements”, too.
I would be against a new x.4 version though, especially if we then had to maintain 6 (soon 7) versions at once!

I’m on Team @bwaidelich :partying_face:

What bugs me a bit about the “leave PHP requirements” option is that someone who’d like to use PHP 7.4 to the full extent doesn’t have an LTS option at the moment. So we’ll force more people to upgrade to 8.0.

Which is a good thing, right?

So we’ll force more people to upgrade to 8.0.

Right now they (who want 7.4 features) don’t have any option at all, so for them they are already bound by what “works” in Flow 7.x. If they do want to use more PHP 7.4 features, having them to upgrade the Flow version (wether to 7.4 or 8.0) is a sane thing to demand IMO. On the contrary, forcing everyone that has been sitting on Flow 7.x with PHP 7.3 confidently till now to upgrade their PHP version just to be able to receive further bug- and security fixes is a no-go. Yes, the PHP upgrade itself might be unproblematic in this case, but what if they have cross-dependencies that restrict installing PHP7.4?
The point is: In some cases upgrading the platform is just not (easily) possible.

someone who’d like to use PHP 7.4 to the full extent doesn’t have an LTS option at the moment.

Well, if we had a conventional LTS strategy that would be a very valid concern I guess. However, since the support cycles of follow-up versions to an LTS receive the same support lifetime as this LTS, this is only an issue on the paper. If you want to go for PHP 7.4+ features, your Flow version of choice will be 8.0 if we stick with “keep requirements”, and you would have the exact same EOL as 7.3 LTS (or a possible 7.4).

That would mean forcing people to do major Neos upgrade. But you just wrote:

So, a major-version upgrade would be fine, but a minor-version upgrade is a no-go? I sense a contradiction here… :sunglasses:

So, a major-version upgrade would be fine, but a minor-version upgrade is a no-go? I sense a contradiction here… :sunglasses:

Not really, because apples&oranges - one case is needing to upgrade a framework (major) in order to develop modern PHP7.4+ code, which is a free decision to make. You could still run with the old code and only upgrade PHP to get further platform security fixes (note Flow 7.x is working on PHP 7.4+, just not able to use it’s new features). The other case is you needing to upgrade your platform (which might not be possible at all), just to be able to keep running the framework version without loss of security upgrades that were promised at the time you installed it.

This last thing specifically is what gets me. We are that way effectively breaching our support promise we make when releasing a (LTS) version - which IMHO would make us untrustworthy.
The disclaimer on the release process is more about retiring versions early that are no longer supportable securely without breaking them (or similarly bad cases of conflict). That’s not at all the case here. We are trying to shove optional platform feature support through a breaking patch-level.

And yes, PHP 7.3 is EOL, but so will be 7.4 in half a year. Neos 7.3 is still to be supported for not quite 3 years. So if that’s the argument, what are we really solving with this? Will we raise the minimum PHP version in 7.3.x to 8 at the end of the year? And 8.1 in another year? This will only lead to us synchronizing our versions to PHP in the end.

1 Like

I’m with Alex on this one and would suggest to go for the “conservative” solution:
The typed class properties for example have a risk of breaking existing things (no offense ofc, but it is a rather low-level change with a lot of touchpoints). I’d like to use that feature, but for LTS versions we should probably focus on stabililty.

I would consider maintaining a separate version 7.4 noch that much effort other than the initial hassle to create the branches. It maily is one extra branch to consider for upmerges and an extra release job to trigger.

I’m a bit unhappy with the poll… the first thing should be a one on one decision: Should the requirements stay frozen or not. Because now two of the options for the “no” votings of this questions get distributed, painting a distorted image of the intentions.

I would agree to anything, but the first question. I hope we take this into account instead of “just” following the winning answer!

1 Like

Aaaand: I cannot take in part in the vote. I guess my User is missing the Role “TeamMember”

I added you to the “Member” group

Its still saying:

You need to be a member of NeosTeam to vote in this poll.

I agree to @fcool that the result is biased by basically splitting the no options into two.

I know quite some Hosters and projects that may run into trouble in a minor update because of that. I also know some good examples of hosters that proactively contact customers and urge them to update but not all customers use those.

I strongly advocate against raising the php version in a bugfix release.
As i undestand it, this defeates the purpose of LTS completely and will cause a lot of grief. What happens if there is a security patch for Neos 7.3? This would be a problem without updating PHP right? In that case this is a no go.
Please dont do it :pray:

1 Like

Thank you for your comments – even though, we probably should have discussed this before starting to vote.

Don’t be afraid of the poll result, there’s no law that we need to take the result as it is, we are still allowed to do what makes sense.

Still, I wanted to clarify one thought:

If we decide to continue supporting PHP 7.3, I’d target my PR for class property type support for Flow 8.0 instead of Flow 7.3 (unless someone volunteers to backport it in a clean way for PHP 7.3). That would leave us with an incomplete support for PHP 7.4 in Flow 7.3.x. Not really dramatic, we didn’t have that support previously.

However, for the packages I maintain, I don’t want to invest the extra work to support different shades of PHP 7.4 syntaxes. My mindset is already focused on PHP 8.1, so it takes a bit of effort to remember 7.4 times. But Phpstorm helps me to check if my code is also PHP 7.4 compatible. What Phpstorm cannot do though is to check if my code works with the specific PHP 7.4 syntax which is supported by Flow 7.3.

/**
  * @Flow\Inject
  * @var Dependency
  */
protected ?Dependency $dependency = null;

:point_up: this won’t work with Flow 7.3

So I just imagine what could go wrong when I upmerge changes and something goes wrong with type hints.

Conclusion: I’d rather not invest the time to support Flow < 8.0 for the packages I maintain.

I’d support Flow 7.4, if there is one which requires PHP 7.4. But I don’t see the big advantage, why someone would upgrade from Flow 7.3 to 7.4 and not to 8.0 right away.

I’m just concerned about the time invest. I can’t imagine that there are more than a handful of users, if any, using a security-patched PHP 7.3 with Flow 7.3. I don’t know any company doing that, not even our enterprise customers do that. And if you use PHP 7.3 without custom security patches, then what’s the big deal to Flow 7.3 without patches? It’s YOLO anyway :wink:

Anyway, I think we got everything on the table now. I guess question is mostly if there enough people who’d like to invest energy into supporting a Flow 7.4 or not. What do you think?

I still think that is all subjective conjecture, we cannot know the numbers, and we don’t know how long distributions might provide security patches to PHP versions in their distributions, making that scenario a potential “safe” scenario to have. I still think Flow 7.4 with the PHP 7.4 support, is the best compromise for everything and the work amount shouldn’t be that big, upmerges between flow 7.3 and 7.4 should be a non issue and hitting one more release button as well.

That all said, I also don#t know the numbers but also suspect it will be a small number that benefits from this. I guess focussing on Flow 8 and having 3rd party packages moving support to Flow >=8 is an option I would be fine with which also pushes updates.

Are you sure about that?
I just tested this exact syntax and it works for me with Flow 7.3 (and PHP 7.4)!

What does not work is if you omit the @var annotation, but even the = null initialization can be removed.


Personally I’d have no problem to drop support for PHP < 7.4 in an LTS version, since that version is officially dead thus people really can’t argue with security.

But I would have issues with a substantial change to the proxy class building in a patch level release.

Maybe we can have a minimal-invasive version that just supports dropping the @var annotation in favor of a type hint though.

Are you sure about that?
I just tested this exact syntax and it works for me with Flow 7.3 (and PHP 7.4)!

Lazy dependencies will break. Check the full example in the description of the PR: FEATURE: Lazy injections for typed properties by robertlemke · Pull Request #2701 · neos/flow-development-collection · GitHub

Anyway, since there was no review activity yet, I think you are right that it’s to complex for a patch level release. On the other hand, I spent more than four days working on it (even if it doesn’t look like that), and I’d like to use it. Therefore I’ll start to rebase this for Flow 8.0, so we may get it ready in time for the feature freeze.

4 Likes