Drop support for PHP 7.x, and PHP 8.0/8.1, new minimum is 8.2. Update PHPUnit to 11.

[robbieaverill]

• Drop PHP 7.x support as it is past EOL, fixes Drop support for PHP 7.x and add support for latest 8.x releases #164
• Drop PHP 8.0/8.1 support as they are in EOL, Drop support for PHP 7.x and add support for latest 8.x releases #164
• Add support for PHP 8.4/5 explicitly (cover in CI test suite), Drop support for PHP 7.x and add support for latest 8.x releases #164
• Add support for installing phpcs 4.x, the latest actively maintained release line, fixes Update to latest PHP Codesniffer version #165
• Update PHPUnit to v11, latest version that supports PHP 8.2+. Fixes Update to latest PHPUnit version #167

This will be released as a new minor release. We won't be adding new features to the existing PHP 7.x/8.0/8.1 release line, so this new release will take the next minor release line. Users should upgrade to a supported PHP version to continue receiving features from this project.

[robbieaverill]

Old artifact, unused so cleaned up.

[sumitramanga]

Hi @robbieaverill Thank you for the PR! This looks good to me. Will just get another set of eyes on it quickly

[TheRealAgentK]

Thx @robbieaverill, this is great.

A couple of additional thoughts:

1. Because we're essentially breaking backwards compatibility for some people on old PHP versions, I think as a release this should be 3.0.0. It seems the jump to 2.0.0 was triggered by a PHP baseline increase as well, so there seems to be precedent.

Not sure if you want to do this in a separate release branch/PR after this PR, but just noticed that you increased it in the README file to 2.4.0

2. The Travis removal is good (ancient history, really), but what that actually shows when I looked at it, is that Travis was (when it was running) executing PHP_CodeSniffer and I don't think the GH Actions do that currently. Is that still worthwhile doing resp. reinstating?

3. This was found by an agentic review run and I haven't validated that myself:

PHP 8.5 deprecates using backticks to execute shell commands. Raygun4PHP’s bundled UUID code still does this:

$ifconfig = ipconfig /all 2>&1;
$ifconfig = ifconfig 2>&1;

When I ran the PR’s tests under PHP 8.5.9, all tests passed, but PHP emitted two deprecation warnings from these lines.

The equivalent supported syntax is:

$ifconfig = shell_exec('ipconfig /all 2>&1');
$ifconfig = shell_exec('ifconfig 2>&1');

This matters because Raygun4PHP captures application errors. Its own deprecation warnings could create noise or potentially be reported as application errors when users enable E_DEPRECATED.

Therefore, adding PHP 8.5 to CI demonstrates that the code still runs, but not that it runs cleanly. The backticks should be replaced and CI should ideally fail on deprecations before the project explicitly advertises PHP 8.5 support

I'm not deeply enough in the PHP world to properly comment on how urgent this would be to fix/change, just wanted to bring it to your attention at least.

[robbieaverill]

Hey @TheRealAgentK, thanks for the reply.

You're right that the 1.x to 2.x release bump was for changing PHP support versions, and I considered that, however I thought it best to keep it as a minor release for a few reasons:

• There is precedent in the wider PHP ecosystem for changing supported PHP versions in minor releases too (e.g. Symphony)
• A major version bump is more difficult for people to upgrade to, so many won't bother
• We are unlikely to be releasing new features in this package for older PHP versions
• Patch versions are still possible against older minor release lines if needed

That said, totally fine with going to a 3.x bump if you'd rather keep it clean!

Re: the PHPCS run, good call - I'll add it to the GH Actions run as part of this PR.

The PHP 8.5 incompatibility I think we should track separately, I'll validate and open a new issue for it.

[TheRealAgentK]

Hey @TheRealAgentK, thanks for the reply.

You're right that the 1.x to 2.x release bump was for changing PHP support versions, and I considered that, however I thought it best to keep it as a minor release for a few reasons:

• There is precedent in the wider PHP ecosystem for changing supported PHP versions in minor releases too (e.g. Symphony)
• A major version bump is more difficult for people to upgrade to, so many won't bother
• We are unlikely to be releasing new features in this package for older PHP versions
• Patch versions are still possible against older minor release lines if needed

That said, totally fine with going to a 3.x bump if you'd rather keep it clean!

Re: the PHPCS run, good call - I'll add it to the GH Actions run as part of this PR.

The PHP 8.5 incompatibility I think we should track separately, I'll validate and open a new issue for it.

Ok, cool - I'm totally happy to go with your recommendation for the version bump to 2.4.0 then. I think that's a reasonable approach with your additional context.

And all good re the other items, too. I think we can approve the PR after the GH actions addition and split out the potential PHP 8.5 code fix into another PR.

[TheRealAgentK]

LGTM now, thx @robbieaverill