I am about to add CI tests using PHP 8.1 and 8.2 to Flow/Neos 7.0+ (because we claim to support php: ^7.3 || ^8.0 there already).
That made me wonder… should we drop tests against PHP 7.3 & 7.4 along the way? Both versions are no longer supported at all, so we could just as well ignore them.
This is related to RFC: Drop PHP 7.3-support in all future Flow versions - bot not really the same, as we could still “support” those versions, but wait for people to actually report if something breaks, as opposed to actively trying to find it.
I would agree to a more agressive policy … however dropping testing with 7.4 would mean end of support for 5.3 LTS-7.3 which still get security updates.
For upgrading? Yes, there are for sure more people doing upgrades at the moment, and that might lead to more support being bought. For most people it seems to be time they tried to save earlier, though…
To keep old versions alive? I doubt that. I for one have zero interest in that. At our company we always try to keep up with current versions, are actively pushing people to end use of PHP 7.4 (so we can drop it from our software stack) and would not go down the path of “patching old stuff to keep it in a zombie state”.
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.
For 6.3, yes, indeed. That at least is security-only by now, so won’t receive many changes anyway if any at all. So I wouldn’t care too much about that version now any more.
But IMHO that would encoirage people to use PHP versions that are implicitly unsafe…
Well, if they decide to use a rather old version of Flow+PHP, they must have reasons (time/resources/money/capacity/life ) so I don’t really think we need to police their PHP version choices.
As said in the other thread back then, I think we can be aggressive with raising minimum PHP versions in our own minor and major releases. That’s a good thing incentivicing people to be up-to-date and secure with new features, but retrospectively cutting support because they won’t/can’t upgrade their platform is a bad move.
We shouldn’t punish people for not being able to keep up, but rather make it as easy as possible for them to do so - make upgrades (at least of our part of the ecosystem) smooth and painless. Not nag them with “Oh you want that latest Flow security fix for the version you installed 2 years ago with our promise to support until next year? Upgrade PHP first! Not because the fix demands it, but because we say so. Oh your other dependency doesn’t allow newest PHP? Too bad.”.
That for me somehow implies we feel guilty of potential security issues in EOL PHP versions. If that’d be our intent, we should really really reconsider our whole LTS strategy/promise - and sync our versions/release cycle to PHP, because that’s what it will then lead to.
TBH. I’d rather keep our own pace and not think too much about users sticking to old versions for whatever reason.
Well, collective responsibility does exist. If everyone just left their vulnerable IoT devices online and thus allowed massive DDoS attacks, would you still consider that unimportant? Might be an extreme example, but…
Also, I remember everyone and their aunt blaming Wordpress for the slow adoption of PHP 7 back then, because they still supported PHP 5.
I think outdated software does pose security risks (and should not be used when networked.)
I fully agree! And tend to think we at least try to do exactly that.
Also, I don’t want to punish anyone – but I don’t want myself or anyone else in the team to suffer by having to care about things required by a software that has been declared dead by it’s maintainers…
Anyway, my main motivation behind this specific question was: Could we shave time off the builds by removing PHP versions. Not more, not less.
We’re FAR AND BEYOND from that though We aggressively do adopt new PHP versions with our releases. The issue of wordpress is a) their spaghetti codebase that is resistant to adopting new code style b) their version policy being “never break anything” [Version Numbering – Make WordPress Core] instead of SemVer (which does explicitly ALLOW breaking to allow moving forward)
Well, collective responsibility does exist.
Indeed and I think we already do our part in making upgrades as smooth as possible. (I’m not diving into the IoT argument, which is too far a stretch really )
I don’t want myself or anyone else in the team to suffer by having to care about things required by a software that has been declared dead by it’s maintainers…
Me neither, but I think the difference is that I do not even think that will happen or is our concern at all. If old-PHP has a servere security flaw, it’s up to PHP to either provide an emergency-patch or our users to upgrade their PHP version (and maybe in the same step upgrade Flow/Neos to be sure about they working together). The actual issue would be, if we would NOT provide a smooth and easy (or any at all!) upgrade path and as you agreed, we at least try to do exactly that We need to provide a path for our users out of the security-flaw, nothing more!
) so I don’t really think we need to police their PHP version choices.
We aggressively do adopt new PHP versions with our releases. The issue of wordpress is a) their spaghetti codebase that is resistant to adopting new code style b) their version policy being “never break anything” [
)