Release 3.0.1 #819
Closed
Release 3.0.1 #819
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Noticed this while having a quick look through the release PR. As this is not a file which is included in the release (`export-ignore`d via `.gitattributes`), I'm pulling this to `develop`.
Quick note on how best to install the dependencies so that `commit check` is ready to go.
This commit adds an initial Dependabot configuration to: * Submit pull requests for security updates and version updates for GH Action runner dependencies. At a later point in time, we could consider enabling it for Composer dependencies as well. The configuration has been set up to: * Run weekly (for now). * The commit messages for PRs submitted by Dependabot will be prefixed according the unofficial conventions used in this repo up to now. * The PRs will automatically be labelled with an appropriate label as already in use in this repo. Refs: * https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file * https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#versioning-strategy
Bumps [actions/checkout](https://github.com/actions/checkout) from 3 to 4. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](actions/checkout@v3...v4) --- updated-dependencies: - dependency-name: actions/checkout dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]>
While looking at this sniff for something unrelated, I started wondering if the signature definitions were still in line with WP Core. Turned out they were not, though with the current checks being done in the sniff, this wasn't necessarily problematic (though it should have been, but that's for another PR). Also see the [additional notes I've added to the review ticket](#507 (comment)). Refs: * https://developer.wordpress.org/reference/classes/wp_widget/wp_widget/ * https://developer.wordpress.org/reference/classes/walker/start_el/ * https://developer.wordpress.org/reference/classes/walker/end_el/ * https://developer.wordpress.org/reference/classes/walker/unset_children/
* Update a URL which is no longer valid. * Ensure all steps have a name.
... which is expected later today. * Builds against PHP 8.3 are no longer allowed to fail. * Add _allowed to fail_ build against PHP 8.4.
The Squizlabs repo has been abandoned. The project continues in a fork in the PHPCSStandards organisation. Ref: * squizlabs/PHP_CodeSniffer 3932
... for improved PHP 8.2 support.
... after the tooling has also updated to the PHPCSStandards version of PHPCS. Refs: * https://github.com/PHPCSStandards/PHPCSUtils/releases * https://github.com/PHPCSStandards/PHPCSExtra/releases
* Include `--dev` in require commands * Use the full term `global` instead of the shorthand `g` * Mirror "Installation" section structure to the structure on WordPress/WordPress-Coding-Standards
PHP_CodeSniffer 3.8.0 now allows for running the tests, which are based on the PHPCS native test suite, with PHPUnit 8 and 9.
This commit updates the package to take advantage of that.
Includes:
* Widening the PHPUnit version requirements.
* Adding the PHPUnit 8+ cache file to `.gitignore`.
* Updating the PHPUnit configuration to make sure that PHP deprecations will always show, even when on a high PHPUnit 9.6 version.
* Updating the info in `CONTRIBUTING`.
* Simplifications to the `quicktest` and `test` workflows.
Also, the code coverage "high" run can now be run against PHP 8.3.
* Running PHPStan against PHP `latest` (couldn't previously be done due to the old PHPUnit version).
* Updating the `unit-tests` script to remove the PHP version based toggle, which is no longer needed.
Ref:
* PHPCSStandards/PHP_CodeSniffer 59
Update some old WPVIP Documentation links.
Since WP 6.0.0, term_exists() uses get_terms() internally`. See core.trac.wordpress.org/ticket/36949. This means that reporting this function as not being cached is not true anymore. Fixes #720.
In WP 6.1.0, `get_page_by_title()` was changed to use `WP_Query` internally`. See core.trac.wordpress.org/ticket/36905. This means that reporting this function as not being cached is not true anymore. Note that since WP 6.2.0, the function was reverted from using `WP_Query` but was deprecated in favour of using `WP_Query` directly. WordPress Coding Standards highlights this deprecation already. See #801.
Bumps [ramsey/composer-install](https://github.com/ramsey/composer-install) from 2 to 3. - [Release notes](https://github.com/ramsey/composer-install/releases) - [Commits](ramsey/composer-install@v2...v3) --- updated-dependencies: - dependency-name: ramsey/composer-install dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]>
Okay, so apparently, there is a long-standing bug in the Microsoft package deploy process which caused `apt-get update` to fail in the first half hour after Microsoft has deployed a package. The failure looks like this: ``` E: Failed to fetch https://packages.microsoft.com/ubuntu/22.04/prod/dists/jammy/InRelease Clearsigned file isn't valid, got 'NOSPLIT' (does the network require authentication?) ``` As this only happens intermittently (after a MS package deploy), the chance of running into this bug are slim, but guess what: today I ran into it. This change to the workflow is intended to prevent the next person running into this issue from having to waste time on figuring this out. By splitting the "Install xmllint" step into two steps: one doing the `apt-get update` and one doing the actual install and making the first step one which is allowed to `continue-on-error`, this issue should hopefully not crop up anymore. Any errors in the `apt-get update` step will now be ignored and as most errors which could potentially come from that step are irrelevant for the rest of the job anyway, this is fine. If a relevant error would be surfaced, the next step (the xmllint install), will fail the job anyway. Refs: * actions/runner-images#3410 * dotnet/core#4167
GaryJones
reviewed
May 2, 2024
| "sirbrillig/phpcs-variable-analysis": "^2.11.17", | ||
| "squizlabs/php_codesniffer": "^3.7.2", | ||
| "squizlabs/php_codesniffer": "^3.8.0", |
There was a problem hiding this comment.
Definitely! Maybe even to 3.9.2 ?
Refs:
| "phpcsstandards/phpcsextra": "^1.1.0", | ||
| "phpcsstandards/phpcsutils": "^1.0.8", | ||
| "phpcsstandards/phpcsextra": "^1.2.1", | ||
| "phpcsstandards/phpcsutils": "^1.0.9", |
jrfnl
reviewed
May 2, 2024
| "phpcsstandards/phpcsextra": "^1.1.0", | ||
| "phpcsstandards/phpcsutils": "^1.0.8", | ||
| "phpcsstandards/phpcsextra": "^1.2.1", | ||
| "phpcsstandards/phpcsutils": "^1.0.9", | ||
| "sirbrillig/phpcs-variable-analysis": "^2.11.17", |
There was a problem hiding this comment.
Also ?
Suggested change
| "sirbrillig/phpcs-variable-analysis": "^2.11.17", | |
| "sirbrillig/phpcs-variable-analysis": "^2.11.18", |
jrfnl
reviewed
May 2, 2024
| "sirbrillig/phpcs-variable-analysis": "^2.11.17", | ||
| "squizlabs/php_codesniffer": "^3.7.2", | ||
| "squizlabs/php_codesniffer": "^3.8.0", | ||
| "wp-coding-standards/wpcs": "^3.0" |
There was a problem hiding this comment.
And:
Suggested change
| "wp-coding-standards/wpcs": "^3.0" | |
| "wp-coding-standards/wpcs": "^3.1.0" |
|
@rebeccahum If I look at the git graph, this branch looks wrong. Looks like everything has been cherrypicked from If I look at the graph for previous releases, there have been one of two different workflows which look to have been followed:
The first workflow seems simplest to me. Was there any particular reason not to do it that way this time ? Maybe time to document the release process properly and add a |
|
Okay, I'll re-make this PR then. |
rebeccahum
added a commit
that referenced
this pull request
May 8, 2024
rebeccahum
added a commit
that referenced
this pull request
May 9, 2024
Update dependencies per #819
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Remaining work for this Milestone
PR for tracking changes for the X.Y.Z release. Target release date: DOW DD MMMM YYYY.
main.