You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -44,7 +45,7 @@ After `composer install`, you can do:
44
45
45
46
## Branches
46
47
47
-
Ongoing development will be done in feature branches then pulled against the `develop` branch and follows a typical _git-flow_ approach, where merges to `master` only happen when a new release is made.
48
+
Ongoing development will be done in feature branches then pulled against the `develop` branch and follows a typical _git-flow_ approach, where merges to `main` only happen when a new release is made.
48
49
49
50
To contribute an improvement to this project, fork the repo and open a pull request to the relevant branch. Alternatively, if you have push access to this repo, create a feature branch prefixed by `fix/` (followed by the issue number) or `add/` and then open a PR from that branch to the default (`develop`) branch.
50
51
@@ -90,7 +91,7 @@ The easiest way to do this is to add a `phpunit.xml` file to the root of your VI
43 sniff test files generated 117 unique error codes; 0 were fixable (0%)
125
+
45 sniff test files generated 175 unique error codes; 0 were fixable (0%)
125
126
126
-
Time: 246 ms, Memory: 32.00 MB
127
+
Time: 150 ms, Memory: 20.00 MB
128
+
129
+
OK (40 tests, 0 assertions)
127
130
```
128
131
129
132
### Unit Testing conventions
130
133
131
-
If you look inside the `WordPressVIPMinimum/Tests` subdirectory, you'll see the structure mimics the `WordPressVIPMinimum/Sniffs` subdirectory structure. For example, the `WordPressVIPMinimum/Sniffs/VIP/WPQueryParams.php` sniff has its unit test class defined in `WordPressVIPMinimum/Tests/VIP/WPQueryParamsUnitTest.php` which checks the `WordPressVIPMinimum/Tests/VIP/WPQueryParamsUnitTest.inc` test case file. See the file naming convention?
134
+
If you look inside the `WordPressVIPMinimum/Tests` subdirectory, you'll see the structure mimics the `WordPressVIPMinimum/Sniffs` subdirectory structure. For example, the `WordPressVIPMinimum/Sniffs/Performance/WPQueryParams.php` sniff has its unit test class defined in `WordPressVIPMinimum/Tests/Performance/WPQueryParamsUnitTest.php` which checks the `WordPressVIPMinimum/Tests/Performance/WPQueryParamsUnitTest.inc` test case file. See the file naming convention?
132
135
133
-
Lets take a look at what's inside `WPQueryParamsUnitTest.php`:
136
+
Let's take a look at what's inside `WPQueryParamsUnitTest.php`:
134
137
135
138
```php
136
139
...
137
-
namespace WordPressVIPMinimum\Tests\VIP;
140
+
namespace WordPressVIPMinimum\Tests\Performance;
138
141
139
142
use PHP_CodeSniffer\Tests\Standards\AbstractSniffUnitTest;
You'll see the line number and number of ERRORs we need to return in the `getErrorList()` method.
@@ -189,23 +206,26 @@ The `--sniffs=...` directive limits the output to the sniff you are testing.
189
206
190
207
The ruleset tests, previously named here as _integration tests_, are our way of ensuring that _rulesets_ do check for the violations we expect them to.
191
208
192
-
An example where it might not would be when a ruleset references a local sniff or a sniff from upstream (WPCS or PHPCS), but that the violation code, sniff name or category name has changed. Without a ruleset test, this would go unnoticed.
209
+
An example where it might not would be when a ruleset references a local sniff or a sniff from upstream (WordPressCS or PHPCS), but that the violation code, sniff name or category name has changed. Without a ruleset test, this would go unnoticed.
193
210
194
-
The `composer check` or `composer test-ruleset` commands run the `ruleset-test.php` files (one for each standard), which internally run `phpcs` against the "dirty" test files (`ruleset-test.inc`), and looks out for a known number of errors, warnings, and messages on each line. This is then compared against the expected errors, warnings and messages to see if there are any missing or unexpected violations or difference in messages.
211
+
The `composer check` or `composer test-ruleset` commands run the `ruleset-test.php` files (one for each ruleset), which internally run `phpcs` against the "dirty" test files (`ruleset-test.inc`), and looks out for a known number of errors, warnings, and messages on each line. This is then compared against the expected errors, warnings, and messages to see if there are any missing or unexpected violations or difference in messages.
195
212
196
213
When adding or changing a sniff, the ruleset test files should be updated to match.
197
214
198
215
## Releases
199
216
200
-
- In a `changelog/x.y.z` branch off of `develop`, update the `CHANGELOG.md` with a list of all of the changes following the keepachangelog.com format. Include PR references and GitHub username props.
201
-
- Create a PR of `develop` <-- `changelog/x.y.z`, but do not merge until ready to release.
202
-
- Create a PR of `master` <-- `develop`, and copy-paste the [`release-template.md`](https://github.com/Automattic/VIP-Coding-Standards/blob/develop/.github/ISSUE_TEMPLATE/release-template.md) contents.
203
-
- When ready to release, merge the change log PR into `develop`, then merge the `develop` into `master` PR.
204
-
- Tag the commit in `master` with the appropriate version number. Ideally, have it signed.
205
-
- Close the current milestone.
217
+
- Create a `release/x.y.z` branch off of `develop`.
218
+
- In a `release/x.y.z-changelog` branch off of `release/x.y.z`, update the `CHANGELOG.md` with a list of all of the changes following the keepachangelog.com format. Include PR references and GitHub username props.
219
+
- Create a PR of `release/x.y.z` <-- `release/x.y.z-changelog`, but do not merge until ready to release.
220
+
- Create any other last-minute PRs as necessary, such as documentation updates, against the release branch.
221
+
- When ready to release, merge the changelog and other branches into `release/x.y.z`.
222
+
- Create a PR of `main` <-- `release/x.y.z`, and copy-paste the [`release-template.md`](https://github.com/Automattic/VIP-Coding-Standards/blob/develop/.github/ISSUE_TEMPLATE/release-template.md) contents.
223
+
- When ready to release, merge `release/x.y.z` into `main`. Undelete the release branch after merging.
224
+
- Tag the commit in `main` with the appropriate version number. Ideally, have it signed.
206
225
- Open a new milestone for the next release.
207
226
- If any open PRs/issues which were milestoned for this release do not make it into the release, update their milestone.
208
-
- Write a Lobby post to inform VIP customers about the release, including the date when the Review Bot will be updated (usually about 1.5 weeks after the VIPCS release).
227
+
- Close the current milestone.
228
+
- Create a PR of `develop` <-- `release/x.y.z` and merge in when ready.
229
+
- Write a Lobby post to inform VIP customers about the release, including the date when the VIP Code Analysis Bot will be updated (usually about 2 weeks after the VIPCS release).
209
230
- Write an internal P2 post.
210
-
- Open a PR to update the [Review Bot dependencies](https://github.com/Automattic/vip-go-ci/blob/master/tools-init.sh).
211
-
231
+
- Open a PR to update the [VIP Code Analysis bot dependencies](https://github.com/Automattic/vip-go-ci/blob/master/tools-init.sh).
Copy file name to clipboardExpand all lines: CHANGELOG.md
+43-1Lines changed: 43 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,6 +4,48 @@ All notable changes to this project will be documented in this file.
4
4
5
5
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
6
6
7
+
## [3.0.0] - 2023-09-05
8
+
9
+
Props: @GaryJones, @jrfnl
10
+
11
+
This release requires [WordPressCS 3.0.0](https://github.com/WordPress/WordPress-Coding-Standards/releases/tag/3.0.0). It is not compatible with WordPressCS 2.x. Users should read the [WordPressCS 3.0 upgrade guide for end-users](https://github.com/WordPress/WordPress-Coding-Standards/wiki/Upgrade-Guide-to-WordPressCS-3.0.0-for-ruleset-maintainers).
12
+
13
+
Increases requirements for PHPCS from 3.7.1 to 3.7.2.
14
+
15
+
The tagged releases branch is now `main` instead of `master`.
16
+
17
+
### Added
18
+
-[#777](https://github.com/Automattic/VIP-Coding-Standards/pull/777): 3.0: start using PHPCSUtils.
19
+
-[#779](https://github.com/Automattic/VIP-Coding-Standards/pull/779): 3.0: support WordPressCS 3.0.
20
+
21
+
## Changed
22
+
-[#780](https://github.com/Automattic/VIP-Coding-Standards/pull/780): Performance/WPQueryParams: defer to the parent sniff.
23
+
- Two error codes changed:
24
+
-`WordPressVIPMinimum.Performance.WPQueryParams.PostNotIn` is now `WordPressVIPMinimum.Performance.WPQueryParams.PostNotIn_post__not_in`.
25
+
-`WordPressVIPMinimum.Performance.WPQueryParams.SuppressFiltersTrue` is now `WordPressVIPMinimum.Performance.WPQueryParams.SuppressFilters_suppress_filters`.
26
+
27
+
### Removed
28
+
-[#774](https://github.com/Automattic/VIP-Coding-Standards/pull/774): Performance/BatcacheWhitelistedParams: remove the sniff.
29
+
-[#775](https://github.com/Automattic/VIP-Coding-Standards/pull/775): Compatibility/Zoninator: remove the sniff.
30
+
-[#776](https://github.com/Automattic/VIP-Coding-Standards/pull/776): Variables/VariableAnalysis: remove the sniff.
31
+
32
+
### Fixed
33
+
-[#784](https://github.com/Automattic/VIP-Coding-Standards/pull/784): Performance/WPQueryParams: prevent false positives for `'exclude'` with `get_users()`.
34
+
-[#788](https://github.com/Automattic/VIP-Coding-Standards/pull/788): Security/Mustache: prevent false positives on block editor templates.
35
+
36
+
### Maintenance
37
+
-[#778](https://github.com/Automattic/VIP-Coding-Standards/pull/778): CS: improve use statements.
38
+
-[#781](https://github.com/Automattic/VIP-Coding-Standards/pull/781): Performance/NoPaging: add extra tests.
39
+
-[#782](https://github.com/Automattic/VIP-Coding-Standards/pull/782): GH Actions: minor tweaks to the composer options used.
0 commit comments