-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update project dependencies and CI workflow #41
Conversation
runs-on: ubuntu-latest | ||
strategy: | ||
matrix: | ||
php-version: ['7.4', '8.0', '8.1', '8.2', '8.3'] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would have personally limited support to PHP 8.1 (and ideally 8.2), as older versions are no longer supported.
However, the WordPress ecosystem is very focused on less technical people, which frequently use outdated shared hosting servers, which make it harder for them to keep their PHP versions up to date.
That's why WordPress supports very old PHP versions and recommends plugin maintainers do the same, otherwise you can find people having problems using your plugin.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How much difference is there between PHP versions? I'm wondering how important it is to have each point release in the test matrix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usually code written for v7.4 should work on newer versions, but this serves as a safety check to be completely sure about this.
At the end of the day, PHP does not follow SemVer, so there could be unexpected breaking changes. Not very usual, but having these checks is cheap, specially considering we don't have control over the envs the plugin will end up running.
@@ -17,6 +17,5 @@ | |||
<exclude-pattern>vendor/</exclude-pattern> | |||
|
|||
<!-- WordPress Coding Standards --> | |||
<rule ref="WordPress-Core"></rule> | |||
<rule ref="WordPress-Extra"></rule> | |||
<rule ref="WordPress-Extra" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WordPress-Extra
includes WordPress-Core
, so there's no need to define both.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks reasonable to me.
runs-on: ubuntu-latest | ||
strategy: | ||
matrix: | ||
php-version: ['7.4', '8.0', '8.1', '8.2', '8.3'] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How much difference is there between PHP versions? I'm wondering how important it is to have each point release in the test matrix.
Part of #40
This PR updates the very few dependencies in the project (mostly the tool for linting, and a plugin with the official WordPress coding standard).
Additionally, it sets a requirement on PHP 7.4 as the minimum supported version, matching latest WordPress requirements.
And last but not least, it moves CI to GitHub Actions for consistency with the rest of our projects, because Travis is no longer free for OSS, and because it is a much better service overall.
The rest of the changes are the result of automatic formatting via
composer format
, after updating to latest coding standard definitions.