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

The Neos Project Neos Project Decisions
42

You’re right. The example above works only if Dependency is a prototype. Otherwise I’ll have to add a lazy=false to the Flow\Inject annotation (or use constructor injection ofc).

I’m sorry if you feel frustrated. I really value your efforts (and I think we all do) and your PR seems like a big improvement in general!

Awesome, thanks!

2 Likes
43

Thanks! I’m also aware, that I should be more humble with this contribution. I can’t make this one PR a big deal (and I try not to) while the rest of the team is busy with many other important changes. I know that I’m currently a low-frequency-code-contributor and appreciate how passionate and diligent you folks work on Neos and Flow. Thanks a lot for that!

4 Likes
44

Coming back to this after about 9 months, realizing we never actually did anything… and by now PHP 7.4 joined the club of dead PHP versions.

So, what do we do? Do we need to do something?

45

I would be fine with leaving flow 7 as it is but improve the php 8 support and use on the 8.x branch that never promised to support php 7.

Personally think that we should be a little more aggressive with adding strict types to flow where we can.

3 Likes
46

Yes :partying_face:

47

We did raise minimum PHP version to 8 in Flow 8, no? So I think we did do something :tada:

Regarding the “^8.0” and this somehow implicitly demanding us to add newer 8.x PHP versions to the build pipeline, I think we should consider to avoid doing “^” version matches, at least for PHP. But that’s a bit of a different topic that would need to be discussed separately. There are valid reasons for and against.

Personally think that we should be a little more aggressive with adding strict types to flow where we can.

Absolutely. The “where we can” is the hard part though :slight_smile: There’s lots of hidden breakiness involved (see my efforts back in time), but I’m all for being agressive in the next major release if someone is up to the task of doing this (hint: psalm has some support for adding this automatically, but ofc needs some vetting)

48

Yes, but given this was about dropping 7.3… :man_shrugging: But yeah.

Maybe we should amend our versioning policy to say we stop supporting PHP versions when they reach EOL. :thinking:

Hm. I oppose and say we should have added PHP 8.2 to our pipleine before it got released to make the needed adjustments. I usually frown upon not testing beta/RC releases, so we should make use of them (in the future). The release process for PHP 8.2 was not a surprise.

Then again, once a version constraint has been opened, it’s too late to dial back, as composer would simply fall back to the newest version that still claims support. So I’d agree to

  • for PHP 9 only do "php": "~9.0.0" and “open up” later combined with
  • testing new minor PHP versions as soon as available in GH Actions
1 Like
50

I think that is the better strategy. Opening up our semver policy to allow for arbitrary breaking changes to update the syntax is not benefitting our users, but only our own need/wish to stay up to date (and maintainable), while we don’t have the capacity to pull it off cleanly within one major release cycle (which with our current branching strategy is ~3months, so yes, let’s fix that!).

say we should have added PHP 8.2 to our pipleine before it got released

That’s not in opposition :slight_smile: I agree! And that’s part of what I intended with the “nightly” build runs that should be able to fail without blocking merges (TASK: Enable PHP nightly build by albe · Pull Request #2524 · neos/flow-development-collection · GitHub)

  • for PHP 9 only do "php": "~9.0.0" and “open up” later combined with
  • testing new minor PHP versions as soon as available in GH Actions

:+1: