I would not drop the builds against the mimium versions we still do claim to support. There’s subtle bugs we could introduce (some PHP 7.4+ syntax has surely become natural for some of us) for what gain? A few less builds on that version that receives bugfixes for one more year.
I would rather argue about our decision to claim “^X.0” PHP support though, because that might have been a bit overly optimistic. We do know that PHP is sometimes pragmatic about semantic versioning (like we are sometimes as well). So maybe we should start only claiming support for PHP versions explicitly that we do run builds against, then introduce support for higher minor versions in bugfix releases? I’d feel this would be more honest than claiming support for anything that comes, then somehow being forced to retroactively “proof” that by adding those new versions to the build pipeline. Yes, that would have prevented e.g. Flow 7.x from being installed on PHP 8.1/8.2 - until we got nagged about it and added support in a bugfix release. But that’s only a bad thing if we were unable to add this increased version support within a reasonable timeframe, say ~2 weeks, given it’s not breaky. If the new version breaks things, then that’s ofc not something we need to “fix” so quickly, but at least we didn’t let users run into this.
Disclaimer: Our build pipeline is of course not a 100% guarantee by any means, but it’s the best we have.
See also RFC: Drop PHP 7.3-support in all future Flow versions - #47 by aberl