chore(deps): require slevomat/coding-standard v8 and squizlabs/php_codesniffer v3.7

[simPod]

• Bump min php to 7.2

[greg0ire]

Drop squizlabs/php_codesniffer as dependency since it's inherited from slevomat/coding-standard

This should be reverted. One should not rely on a dependency being transitively installed when referencing things defined in it, and we do:

coding-standard/lib/Doctrine/ruleset.xml

Line 17 in f86c16a

<exclude name="Squiz.Functions.FunctionDeclarationArgumentSpacing.SpacingAfterVariadic"/>

I think this needs 10.0.x

Why?

[simPod]

@greg0ire ad 10.0.x: this is a BC break https://github.com/doctrine/coding-standard/pull/264/files#diff-d9e16eb577617c038e05ad72a5a3dd5f93f23fd798bf4b35d668b173a9c5733bR137 sniff got renamed

[greg0ire]

How is it a BC-break? That sniff is not part of the public API of doctrine/coding-standard, is it?

[simPod]

I though of a case when user e.g. excluded that sniff by a name. The sniff is enabled by Doctrine CS. Not sure if it's considered BC break or not or what's actually a public api in the context of CS. 🤷🏿‍♀️ Ur call.

[greg0ire]

by a name

If that name is defined by slevomat/coding-standard, then they should require it beforehand. In practice, we don't seem to be doing so ourselves (if you look for instance at doctrine/dbal), but what I mean is that people cannot really complain to us about a BC-break in this case.

what's actually a public api in the context of CS

I think it this case, the public API is the name Doctrine in <rule ref="Doctrine"/>, and that's it.

[derrabus]

If I may weigh in on the target version discussion: If this change does not justify a major version bump (10.0.0), it certainly deserves a minor version bump (9.1.0) because I believe this is not just a bugfix.

[greg0ire]

If I may weigh in on the target version discussion: If this change does not justify a major version bump (10.0.0), it certainly deserves a minor version bump (9.1.0) because I believe this is not just a bugfix.

I think you're correct, so I should a create a 9.1.x branch so that this can be retargeted.

Looking at 9.0.0...9.0.x though, I see a couple PRs we all reviewed (including myself 😅 ) have been targeted at the wrong branch (IMO):

• Add RequireOneLineDocComment sniff #252
• Require Null Safe Object operator #255

I say we merge this one in 9.0.x as well, then merge 9.0.x up into 10.0.x, and release 10.0.0, and then we try to stick to semver 😄

I can contribute more details to https://www.doctrine-project.org/projects/doctrine-coding-standard/en/8.2/reference/index.html#versioning but I think both PRs above are already covered by that paragraph.

[simPod]

With v10 lets wait I have few PRs to add

[ostrolucky]

Somebody with admin rights has to merge this...

[greg0ire]

Thanks @simPod !