2.2.0

.gitattributes

@@ -0,0 +1,29 @@
+#
+# Exclude files from release archives.
+# This will also make them unavailable when using Composer with `--prefer-dist`.
+# If you develop for VIPCS using Composer, use `--prefer-source`.
+# https://blog.madewithlove.be/post/gitattributes/
+#
+/.editorconfig export-ignore
+/.gitattributes export-ignore
+/.gitignore export-ignore
+/.phpcs.xml.dist export-ignore
+/.travis.yml export-ignore
+/phpunit.xml.dist export-ignore
+/.github export-ignore
+/bin export-ignore
+/tests export-ignore
+/WordPressVIPMinimum/Tests export-ignore
+
+#
+# Auto detect text files and perform LF normalization
+# http://davidlaing.com/2012/09/19/customise-your-gitattributes-to-become-a-git-ninja/
+#
+* text=auto
+
+#
+# The above will handle all files NOT found below
+#
+*.md text
+*.php text
+*.inc text

.github/CODEOWNERS

@@ -0,0 +1,4 @@
+# The following teams will get auto-tagged for a review.
+# See https://docs.github.com/en/enterprise/2.15/user/articles/about-code-owners
+
+* @Automattic/vipcs

CONTRIBUTING.md → .github/CONTRIBUTING.md

@@ -7,11 +7,24 @@ Hi, thank you for your interest in contributing to the VIP Coding Standards! We
 Before reporting a bug, you should check what sniff an error is coming from.
 Running `phpcs` with the `-s` flag will show the name of the sniff with each error.
 
+Please search the repository before opening an issue to verify that the issue hasn't been reported already.
+
 Bug reports containing a minimal code sample which can be used to reproduce the issue are highly appreciated as those are most easily actionable.
 
 ### Upstream Issues
 
-Since VIPCS employs many sniffs that are part of PHPCS, and makes use of WordPress Coding Standards sniffs, sometimes an issue will be caused by a bug upstream and not in VIPCS itself. If the error message in question doesn't come from a sniff whose name starts with `WordPressVIPMinimum`, the issue is probably a bug in PHPCS itself, and should be [reported there](https://github.com/squizlabs/PHP_CodeSniffer/issues).
+Since VIPCS employs many sniffs that are part of PHPCS, and makes use of WordPress Coding Standards sniffs, sometimes an issue will be caused by a bug upstream and not in VIPCS itself. If the error message in question doesn't come from a sniff whose name starts with `WordPressVIPMinimum`, the issue is probably an upstream bug.
+
+To determine where best to report the bug, use the first part of the sniff name:
+
+Sniffname starts with | Report to
+--- | ---
+`Generic` | [PHP_CodeSniffer](https://github.com/squizlabs/PHP_CodeSniffer/issues/)
+`PSR2` | [PHP_CodeSniffer](https://github.com/squizlabs/PHP_CodeSniffer/issues/)
+`Squiz` | [PHP_CodeSniffer](https://github.com/squizlabs/PHP_CodeSniffer/issues/)
+`VariableAnalysis` | [VariableAnalysis](https://github.com/sirbrillig/phpcs-variable-analysis/issues/)
+`WordPress` | [WordPressCS](https://github.com/WordPress/WordPress-Coding-Standards/issues/)
+`WordPressVIPMinimum` | [VIPCS](https://github.com/Automattic/VIP-Coding-Standards/issues/) (this repo)
 
 ----
 
@@ -42,7 +55,7 @@ The sniffs and test files - not test _case_ files! - for VIPCS should be written
 When writing sniffs, always remember that any `public` sniff property can be overruled via a custom ruleset by the end-user.
 Only make a property `public` if that is the intended behaviour.
 
-When you introduce new `public` sniff properties, or your sniff extends a class from which you inherit a `public` property, please don't forget to update the [public properties wiki page](https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/wiki/Customizable-sniff-properties) with the relevant details once your PR has been merged into the `develop` branch.
+When you introduce new `public` sniff properties, or your sniff extends a class from which you inherit a `public` property, please don't forget to update the [public properties wiki page](https://github.com/Automattic/VIP-Coding-Standards/wiki/Custom-properties-for-VIPCS-Sniffs) with the relevant details once your PR has been merged into the `develop` branch.
 
 ## Unit Testing
 
@@ -61,7 +74,7 @@ N.B.: If you installed VIPCS using Composer, make sure you used `--prefer-source
 If you already have PHPUnit installed on your system: Congrats, you're all set.
 
 If not, you can navigate to the directory where the `PHP_CodeSniffer` repo is checked out and do `composer install` to install the `dev` dependencies.
-Alternatively, you can [install PHPUnit](https://phpunit.de/manual/5.7/en/installation.html) as a PHAR file.
+Alternatively, you can [install PHPUnit](https://phpunit.readthedocs.io/en/7.5/installation.html) as a PHAR file.
 
 ### Before running the unit tests
 
@@ -71,11 +84,13 @@ For the unit tests to work, you need to make sure PHPUnit can find your `PHP_Cod
 
 The easiest way to do this is to add a `phpunit.xml` file to the root of your VIPCS installation and set a `PHPCS_DIR` environment variable from within this file. Make sure to adjust the path to reflect your local setup.
 ```xml
-<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-	xsi:noNamespaceSchemaLocation="https://schema.phpunit.de/6.3/phpunit.xsd"
-	beStrictAboutTestsThatDoNotTestAnything="false"
-	bootstrap="./tests/bootstrap.php"
+<?xml version="1.0" encoding="UTF-8"?>
+<phpunit
+	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+	xsi:noNamespaceSchemaLocation="https://schema.phpunit.de/7.2/phpunit.xsd"
 	backupGlobals="true"
+	bootstrap="./tests/bootstrap.php"
+	beStrictAboutTestsThatDoNotTestAnything="false"
 	colors="true">
 	<php>
 		<env name="PHPCS_DIR" value="/path/to/PHP_CodeSniffer/"/>
@@ -86,7 +101,7 @@ The easiest way to do this is to add a `phpunit.xml` file to the root of your VI
 ### Running the unit tests
 
 * Make sure you have registered the directory in which you installed VIPCS with PHPCS using;
-    
+
     ```sh
     phpcs --config-set installed_paths path/to/VIPCS
     ```
@@ -99,13 +114,13 @@ The easiest way to do this is to add a `phpunit.xml` file to the root of your VI
 
 Expected output:
 ```
-PHPUnit 7.5.12 by Sebastian Bergmann and contributors.
+PHPUnit 7.5.20 by Sebastian Bergmann and contributors.
 
-...........................................                       43 / 43 (100%)
+..........................................                        42 / 42 (100%)
 
-44 sniff test files generated 119 unique error codes; 0 were fixable (0%)
+43 sniff test files generated 117 unique error codes; 0 were fixable (0%)
 
-Time: 380 ms, Memory: 30.00MB
+Time: 246 ms, Memory: 32.00 MB
 ```
 
 ### Unit Testing conventions
@@ -178,3 +193,18 @@ An example where it might not would be when a ruleset references a local sniff o
 The `composer test` or `composer 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.
 
 When adding or changing a sniff, the ruleset test files should be updated to match.
+
+## Releases
+
+- 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.
+- Create a PR of `develop` <-- `changelog/x.y.z`, but do not merge until ready to release.
+- 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.
+- When ready to release, merge the change log PR into `develop`, then merge the `develop` into `master` PR.
+- Tag the commit in `master` with the appropriate version number. Ideally, have it signed.
+- Close the current milestone.
+- Open a new milestone for the next release.
+- If any open PRs/issues which were milestoned for this release do not make it into the release, update their milestone.
+- 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).
+- Write an internal P2 post.
+- Open a PR to update the [Review Bot dependencies](https://github.com/Automattic/vip-go-ci/blob/master/tools-init.sh).
+

.github/ISSUE_TEMPLATE/release-template.md

@@ -9,13 +9,13 @@ assignees: GaryJones, rebeccahum
 
 ⚠️ DO NOT MERGE (YET) ⚠️
 
-Please do add approvals if you agree.
+[Remaining work for this Milestone](https://github.com/Automattic/VIP-Coding-Standards/milestone/X)
 
-PR for tracking changes for the 2.x.y release. Target release date: DOW DD MMMM.
+PR for tracking changes for the X.Y.Z release. Target release date: DOW DD MMMM YYYY.
 
-- [ ] Add changelog for this release.
+- [ ] Add change log for this release: PR #XXX
 - [ ] Merge this PR.
-- [ ] Add release tag against `master`.
+- [ ] Add signed release tag against `master`.
 - [ ] Close the current milestone.
 - [ ] Open a new milestone for the next release.
 - [ ] If any open PRs/issues which were milestoned for this release do not make it into the release, update their milestone.

.gitignore

@@ -1,3 +1,4 @@
+build/
 vendor/
 composer.lock
 phpcs.xml

.phpcs.xml.dist

@@ -16,6 +16,8 @@
 	<rule ref="WordPress-Extra">
 		<exclude name="WordPress.Files.FileName"/>
 		<exclude name="WordPress.NamingConventions.ValidVariableName"/>
+		<exclude name="Generic.Arrays.DisallowShortArraySyntax"/>
+		<exclude name="WordPress.PHP.YodaConditions"/>
 	</rule>
 
 	<rule ref="WordPress-Docs"/>
@@ -31,16 +33,14 @@
 
 	<rule ref="PSR2.Methods.FunctionClosingBrace"/>
 
-	<!-- Disallow long array syntax -->
+	<!-- Disallow long array syntax. -->
 	<rule ref="Generic.Arrays.DisallowLongArraySyntax"/>
 
-	<!-- Allow short array syntax -->
-	<rule ref="Generic.Arrays.DisallowShortArraySyntax.Found">
-		<exclude name="Generic.Arrays.DisallowShortArraySyntax.Found"/>
-	</rule>
+	<!-- Disallow Yoda conditions. -->
+	<rule ref="Generic.ControlStructures.DisallowYodaConditions"/>
 
 	<!-- Check code for cross-version PHP compatibility. -->
-	<config name="testVersion" value="5.6-"/>
+	<config name="testVersion" value="5.4-"/>
 	<rule ref="PHPCompatibility">
 		<!-- Exclude PHP constants back-filled by PHPCS. -->
 		<exclude name="PHPCompatibility.PHP.NewConstants.t_finallyFound"/>

.travis.yml

@@ -1,6 +1,6 @@
 language: php
 os: linux
-dist: trusty
+dist: xenial
 
 env:
   # `master` is now 3.x.
@@ -13,8 +13,6 @@ cache:
     - $HOME/.cache/composer/files
 
 php:
-  - 5.4
-  - 5.5
   - 5.6
   - 7.0
   - 7.1
@@ -69,6 +67,20 @@ jobs:
         # Run PHPCS against VIPCS.
         - ./bin/phpcs
 
+    # Builds which need a different distro.
+    - stage: test
+    - php: 5.5
+      dist: trusty
+      env: PHPCS_BRANCH="dev-master"
+    - php: 5.5
+      dist: trusty
+      env: PHPCS_BRANCH="3.5.5"
+    - php: 5.4
+      dist: trusty
+      env: PHPCS_BRANCH="dev-master"
+    - php: 5.4
+      dist: trusty
+      env: PHPCS_BRANCH="3.5.5"
 
 before_install:
   # Speed up build time by disabling Xdebug.