Page MenuHomePhabricator

Make release v41.0.0 of mediawiki/mediawiki-codesniffer
Closed, ResolvedPublic

Event Timeline

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

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).

Jdforrester-WMF renamed this task from Next release of mediawiki/mediawiki-codesniffer after v40.0.1 to Make release v41.0.0 of mediawiki/mediawiki-codesniffer.Jan 20 2023, 5:00 PM
Jdforrester-WMF subscribed.

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.

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

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