Long anticipated, finally here: PHPCompatibility 10.0.0-alpha1 🎉
PHPCompatibility 10.0.0 brings huge improvements in both what is being detected (> 50 new sniffs), as well as the detection accuracy for pre-existing sniffs.
Even though still "unstable", it is stable enough for our purposes and the advantages of using it outweigh the disadvantage of it being an unstable version. By setting the `minimum-stability` and `prefer-stable` settings in the `composer.json`, we can ensure that we don't get the `dev-develop` branch, but rather get a `10.0.0` tag, unstable or not.
Includes updating the PHPCS version constraints to match.
Includes updating the exclusions in the ruleset for changes in the error codes due to further changes in PHP having been made (and now being detected).
Ref:
* https://github.com/PHPCompatibility/PHPCompatibility/wiki/Upgrading-to-PHPCompatibility-10.0
* https://github.com/PHPCompatibility/PHPCompatibility/releases/tag/10.0.0-alpha1
... which is expected to be released this Thursday.
* Builds against PHP 8.5 are no longer allowed to fail.
* Update PHP version on which code coverage is run (high should now be 8.5).
* Add _allowed to fail_ build against PHP 8.6.
* Update the README.
Note: for some jobs I use "nightly" for the "next" PHP version, for some `8.6`. While it may appear there is no difference and this is true for the better part of the year, there is a difference for about two months.
To illustrate, consider PHP 8.5:
* PHP "nightly" refers to the PHP `master` branch, so was PHP 8.5 until the PHP 8.5 was branched off when the first RC was cut in September.
* As of that moment, "nightly" basically became PHP 8.6, so to test against PHP 8.5, one would need to explicitly request `8.5`.
* As of the release of PHP 8.5, it is expected for "nightly" to be PHP 8.6, so the difference is moot again.
For that reason, the unit test workflow uses the explicit `8.6` version for PHP "next".
As things were, test runs on forks would always fail on the "upload code coverage reports" step, as forks (justifiably) don't have access to the `CODECOV_TOKEN`.
Fixed now by updating the conditions to run that step.
The `roave/security-advisories` package was an inventive method to block installation of known insecure versions of other dependencies (via a `conflict` annotation).
As of Composer 2.9, using the `roave/security-advisories` package for this purpose is no longer needed as Composer will now natively block installation of known insecure versions of dependencies.
And while not all contributors to this repo may be using Composer 2.9+ (yet), Composer 2.9+ **_will_** be used in CI and CI failing on Composer blocking an insecure dependency offers the same level of protection as the package previously offered.
Refs:
* https://blog.packagist.com/composer-2-9/
* https://github.com/composer/composer/releases/tag/2.9.0
If generating an OAuth2 token fails in the provider and an exception is thrown, we never catch that exception, but just let exception propagate up to whatever.
I suggest this change, such that we can handle errors when generating oauth tokens. It is based on the fact that ^League\OAuth2\Client\Provider\AbstractProvider` can throw exceptions during getting the oauth token, but we are nowhere near to knowing why.
I have decided on catching all exception (`\Exception`) because if someone uses another OAuthTokenProvider (it's just an interface, so it's possible), we won't know specifically which exceptions can be thrown here, so we need to catch them all.
By throwing a PHPMailer exception and adding the existing exception as the `$previous` variable, we can show a generic error message to regular users and advice how developers can get actually meaningful error messages from the previous exception.
jrfnl
Marcus Bointon
Robin van der Vliet
dependabot[bot]
Jesper Skytte
Adrian Thomassen
Adrian Thomassen
Daniel Kamiński
Mariusz Krzaczkowski