PHP 7.* is end of life remove support/testing

[whikloj]

No description provided.

[whikloj]

@staabm @jmglsn do/did you have a process or plan for releases and support?

I think a new release that supports PHP 8.1,8.2 is needed. It could be a 5.1.0. I'd like to add that tag sooner rather than later.

It would also be good to replace all those #[\ReturnTypeWillChange] annotations @danesteve added with actual return types, but that means ending support for older versions of PHP.

[staabm]

leaving #[\ReturnTypeWillChange] in for a bit so we have wider php version support should be the way to go in my opinion. does #[\ReturnTypeWillChange] incur a problem as you are trying to drop it in the short term?

I am fine with tagging a new release

[whikloj]

There is no problem with leaving the annotations in, however as return types were added in PHP 7.0 this would indicate an attempt to continue support for versions of PHP older than 7.0. Issue #78 was about dropping support for PHP 5.5/5.6.

I am just wondering how large the window of versions of PHP that should be supported. As new versions appear and some people upgrade it makes for a larger window to continue support if old ones are not removed.

PHP 7.4 became end of life 2022-11-28 and 8.3.0 is scheduled for release 2023-11-23. So the question is what is an adequate time frame to allow users to upgrade their PHP installations? End of life plus a year?

I'll will tag a 5.1.0 release.

[whikloj]

Actually just noticed that the composer.json restricts stomp-php to PHP 7.3 or 8.* anyways.
https://github.com/stomp-php/stomp-php/blob/master/composer.json#L28

So no one is using 5.6, the only question is how long to support 7.3 and 7.4.

[staabm]

since 7.x is still part of LTS linux distributions, I would give them more time.

if we have a concrete problem to solve, because of PHP7 support we can re-discuss. I don't see value atm in dropping 7.x