I don't see any upstream releases of https://github.com/squizlabs/PHP_CodeSniffer likely to be made for a while (no changes on master in nearly 2 months)

However, https://github.com/squizlabs/PHP_CodeSniffer/issues/3726 would be appropriate to bring in if a 3.7.2 release was made... Plus https://github.com/squizlabs/PHP_CodeSniffer/milestone/30?closed=1

Cross link T266890: Establish a regular release process for codesniffer

This should probably be v41.0.0, since Forbid eval() is a breaking change (and you can see in mw-tools-codesniffer-mwcore-testrun, e.g. #2789, that it actually produces a handful of errors in MediaWiki core, which we’ll presumably resolve by disabling the sniff per-line).

In T325201#8468476, @Lucas_Werkmeister_WMDE wrote:

This should probably be v41.0.0, since Forbid eval() is a breaking change

Ack.

Should we continue to wait for upstream or just do this?

Isn't the process that rules that are new or more strict than before (which is something we regularly do, not only because of eval) get disabled by the update bot via an exclude in .phpcs.xml? This can then be improved (e.g. replaced with individual exclusions per line) any time later. If a release is "breaking" or not shouldn't be that relevant because of this.

In T325201#8544686, @thiemowmde wrote:

Isn't the process that rules that are new or more strict than before (which is something we regularly do, not only because of eval) get disabled by the update bot via an exclude in .phpcs.xml? This can then be improved (e.g. replaced with individual exclusions per line) any time later. If a release is "breaking" or not shouldn't be that relevant because of this.

That is the case for our automatic upgrades via libup, but just because the rules can be disabled doesn't mean the change isn't breaking - my understanding of semantic version is that new errors are always a breaking change

In T325201#8567884, @DannyS712 wrote:

In T325201#8544686, @thiemowmde wrote:

Isn't the process that rules that are new or more strict than before (which is something we regularly do, not only because of eval) get disabled by the update bot via an exclude in .phpcs.xml? This can then be improved (e.g. replaced with individual exclusions per line) any time later. If a release is "breaking" or not shouldn't be that relevant because of this.

That is the case for our automatic upgrades via libup, but just because the rules can be disabled doesn't mean the change isn't breaking - my understanding of semantic version is that new errors are always a breaking change

Exactly. Situationally not-breaking-your-code isn't non-breaking. :-)

Change 892001 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/tools/codesniffer@master] Release v41.0.0

https://gerrit.wikimedia.org/r/892001

Change 892001 merged by jenkins-bot:

[mediawiki/tools/codesniffer@master] Release v41.0.0

https://gerrit.wikimedia.org/r/892001

Change 892008 had a related patch set uploaded (by Jforrester; author: Jforrester):

[labs/libraryupgrader/config@master] releases: Bump codesniffer to 41.0.0

https://gerrit.wikimedia.org/r/892008

Change 892008 merged by jenkins-bot:

[labs/libraryupgrader/config@master] releases: Bump codesniffer to 41.0.0

https://gerrit.wikimedia.org/r/892008