Include VIP Coding Standards with 10up Default.

[peterwilsoncc]

Description of the Change

Since 10up/phpcs-composer@5f9ac99 the 10up Default coding standards require the WordPress VIP sniffs be installed. This includes the sniffs with the 10up-Default ruleset.

Closes #24

How to test the Change

Changelog Entry

Fixed - Include WP VIP coding standards with 10up-Default sniffs.

Credits

Props @peterwilsoncc

Checklist:

• I agree to follow this project's Code of Conduct.
• I have updated the documentation accordingly.
• I have added tests to cover my change.
• All new and existing tests pass.

[cadic]

LGTM.

Works as expected: 10up/simple-podcasting@1a97247

May produce new errors and warnings on existing projects because of rulesets change.

[peterwilsoncc]

LGTM.

Works as expected: 10up/simple-podcasting@1a97247

May produce new errors and warnings on existing projects because of rulesets change.

@cadic @dkotter Do you think we should hold of merging for now and consider changing to using numbered versions in the OSP repos, rather than stable?

[dkotter]

Do you think we should hold off merging for now and consider changing to using numbered versions in the OSP repos, rather than stable?

Hmm... yeah, not sure here. I recently thought that we should change all our public Actions to use version numbers in their releases, which seems to be the standard there (so instead of including stable or a release like 2.0.0, you include v1 or v2. I don't think our Actions work like this right now).

That's a slightly different, though similar, thing then what's at play here. The concern as I see it here is if we merge this in, it could start causing failures on existing projects due to the new rules. While it would be great to update any project that uses this Action to reference a tagged release instead of stable, not sure how realistic that is.

I guess I lean towards merging this in and not seeing it as a bad thing if new issues are flagged that need fixed. But then would love to get on a more normal release pattern (and update docs) so projects aren't loading straight from stable. Any thoughts on this @jeffpaul?

[jeffpaul]

1. I'm fine merging this in.
2. I'm fine with projects referencing stable if we effectively want to be on the latest version of an action.
3. I'm also with projects referencing a specific release branch, e.g. v2, if we want to maintain functionality and avoid breaking changes.

So, kinda saying... YOLO I guess?

[peterwilsoncc]

Thanks Jeff. YOLO!