Supported PHP versions in changelog 4.10.0-beta1

[xini]

I am having an issue with the support of PHP versions as outlined in https://github.com/silverstripe/silverstripe-framework/blob/4/docs/en/04_Changelogs/beta/4.10.0-beta1.md#dropping-support-for-php-71-and-php-72phpeol.

I do understand that you don't want to support PHP 7.1 and 7.2 (even though "have been end-of-life for several years" might be a bit exaggerated...).
But PHP 7.3 just went EOL two days ago and you want to drop support for it "later this year" aka in the next 22 days?!

You seem to be very quick at dropping support for older versions of PHP, but to get Silverstripe to officially support PHP 8.0 has taken over a year and PHP 8.1 is already out as well.

I'm not sure what the solution is but I think we should at least talk about it?

Cheers

[michalkleiner]

There's also 7.4 available after 7.3 which works fine without major hurdles as far as our project experience goes.
Is 7.4 a potential path for you before adopting PHP 8 or newer?

[xini]

Hi Michael, I know. But that's not the point, is it.

[kinglozzer]

The RFC about this: #10102.

I think it’s perfectly reasonable to drop support for a PHP version as soon as it’s EOL. An EOL version should be considered vulnerable, and shouldn’t be used to run production websites. I know that we don’t live in the “ideal world” where everyone updates their PHP version regularly, but we’ll still be providing security fixes to 4.8 - 4.10, and by extension older PHP versions that those releases support, for a while yet. You just won’t be able to upgrade to the next minor release for new features unless you also upgrade your PHP version. Perhaps that distinction needs to be made clearer in the documentation?

We should definitely update that document to avoid using terms like “this year”, as it will soon be incorrect.

[michalkleiner]

Hi Michael, I know. But that's not the point, is it.

No, no, all good, I understood your initial issue. I also saw people somewhat forgetting there's 7.4 and basically seeing 7.3 and then jumping straight to 8, so I just wanted to bring that up.

[xini]

@michalkleiner no worries. Funny. For me it's been 7.2 > 7.4 > 8.1, skipping 7.3 and 8.0 completely.

@kinglozzer I understand. But maybe, as long as SS works woth older versions, it should be up to the developer to decide what version to go with? Also, if older versions are dropped immediately, there should be a focus to support new versions so that it doesn't take a year to get official support? How is suppoet for 8.1 looking?

[GuySartorelli]

I assumed the "this year" note meant 4.10 wouldn't be released until 2022, since that's a really quick turnaround to go from 4.10 to 4.11... is that not the case?

[xini]

I think dropping support for a PHP version should only be done if technically necessary. Like dropping support for 7.1 and 7.2 because of the new PHPUnit version. That's fine.

Dropping support for PHP 7.3 is not necessary and it doesn't hurt to keep the build tasks in the matrix until some dependency requires for 7.3 to be dropped.

It is the dev's responsibility to run a site on a certain PHP version. Locking someone out of fixes and improvements to Silverstripe because their server environment is not up to scratch is irresponsible.

If you hold on to dropping support for PHP versions as soon as they go EOL, I expect in return that you deliver a SS version compatible with new PHP versions as soon as they are released. PHP 8.1 was released on 25/11/21 and is not even mentioned in any SS issues/PRs yet (apart from this one).

[GuySartorelli]

Supporting a version of PHP that is EOL increases the burden of tests and means we can't take advantage of newer syntax, which is worth considering.
Also I can't think of a situation where someone would be intentionally leaving PHP out of date but taking time to update their website dependencies.

[xini]

@GuySartorelli if dropping support is necessary to get a certain feature and would need ridiculous workarounds otherwise, I'm not against it. But as i said, only if necessary.
Not every developer has access to the server environment. I see it all the time where organisations don't give their devs access to do everything on a server. Not everyone is running their sites in containers. In a lot of organisations deployments are automated from a git repository, so that a composer update and deployment of the site is easy, but upgrading PHP is not.

[GuySartorelli]

I'm going to close this issue - github issues isn't the place to talk about policy with the exception of RFCs, and there hasn't been any discussion in this issue since January in any case.

[xini]

@GuySartorelli where is that place to discuss policy then?

[GuySartorelli]

On the RFC (#10102) in this case. Given that it was already accepted I don't think it's likely for that to be changed, but that's where the discussion should be.

[xini]

@GuySartorelli I. That case I request a mailing list for new RFCs, for people to be informed of new RFCs. Or you setup a have-your-say voting platform on all RFC topics so that the wider community can have a say.

[xini]

Work with the community, not against it.

[GuySartorelli]

a mailing list for new RFCs

That's a good idea! I'll bring that up. Thank you for suggesting that.

Work with the community, not against it.

We're trying - there are obviously some situations where our best doesn't match everyone's expectations. We're working on improving how we do things and being more transparent, but it's a process.

[xini]

Thank you.