Change link to PHP coding standards

[MauricioFauth]

Replaces the version from master with the version from PHP-8.5.

I think it's better to point to a more static version of the PHP coding standards than the version from the master branch. Using a tag instead of a branch would be even better.

[samdark]

That will require adjustments every PHP release, which I don't think is a good idea.

[MauricioFauth]

That will require adjustments every PHP release, which I don't think is a good idea.

It doesn't need to be updated. It will only require adjustment when that specific quote from PHP Coding Standard gets updated, but that will require discussion and a new version of this standard.

This standard recommends a specific version of that section of the PHP Coding Standard. Currently the master branch have that version, but this may not be true in the future. I don't think this uncertainty is safe for a standard to have.

[Crell]

It's a specific subset of the PHP coding standards that we're referencing. Were PHP to change that specific clause, would we want to follow suit automatically? That's the main question.

In this case, we're saying "we follow PHP's rules." So if those change, so would we.

So... I think it's more of a question for implementers. Would having PER-CS 3.1 subtly change if that part of PHP's coding standards change cause an issue for you? Would you rather it be pinned and then bumped at the next point release? (Pinging @jrfnl et al.)

(I think this is mostly a theoretical/conceptual concern, as that specific rule is unlikely to change any time soon.)

[jrfnl]

It's a specific subset of the PHP coding standards that we're referencing. Were PHP to change that specific clause, would we want to follow suit automatically? That's the main question.

In this case, we're saying "we follow PHP's rules." So if those change, so would we.

So... I think it's more of a question for implementers. Would having PER-CS 3.1 subtly change if that part of PHP's coding standards change cause an issue for you? Would you rather it be pinned and then bumped at the next point release?

Theoretical or not, PER should IMO follow semver and that means that such a change will need to be made in a minor if it is compatible with the previous version of the same rule; or in a major when the new rule is incompatible (changed substantially) compared to the previous version of the rule.

Following suit should not be automatic, but deliberate.

Automatic would always cause a problem. Think: PER 3.1.0 would be released Oct 2026, the rule in PHP changes in April 2027 and PER 3.2.0 only gets released in December 2027.
Now the question becomes: which rule should a tooling ruleset enforce ? The pre-April one (as in the rule as it was when PER 3.1.0 was released) or the post-April one ("current" rule) ?

In other words: please pin and make updates of the rule explicit in a new version of the PER standard.

I know, I'm also talking theoretically, as PHPCS doesn't have a functioning PER enforcement standard yet, but the way I've proposed for it to be set up, is with a ruleset for each version of PER, so users don't suddenly get confronted with failing builds if changes from a new PER version get implemented (providing they don't use the death-star and such).

Does that help ?