[TASK] Update the development tools

[oliverklee]

No description provided.

[coveralls]

coverage: 97.062%. remained the same
when pulling 44cc3e2 on task/update-dev-tools
into 97cf851 on main.

[JakeQZ]

Ah, I see, it breaks something, and this PR is now 'draft'.

Personally (YMMV), I'm not super-keen to update things if there's no need to. If it ain't broke, don't fix it (because you'll just end up breaking more stuff).

The PHIVE PHARs will be installed with the latest permissable version locally upon running phive update. Do we not also run that during CI? If so, we don't need to keep updating these files. If not, maybe we should - ?

We concluded that we needed to restrict versions of the static analysis tools in Composer to avoid breaking updates, though I wonder if we might be able to use Tilde Version Range - if the tools really adhere to semver, then point releases should not break anything.

No specific changes requested beyond fixing the CI.

[JakeQZ]

We should probably use ~ version in the PHIVE config, so that contributors don't pick up breaking changes.

[oliverklee]

Personally (YMMV), I'm not super-keen to update things if there's no need to. If it ain't broke, don't fix it (because you'll just end up breaking more stuff).

Okay, then let's only update the tools when they either bring features of bug fixes we need/want, or when we'll need to update our code for the new version.

The PHIVE PHARs will be installed with the latest permissable version locally upon running phive update. Do we not also run that during CI? If so, we don't need to keep updating these files. If not, maybe we should - ?

CI is running phive install (not phive update) to get the exact versions specified as installed in phars.xml. That's what contributors are expected to use and what's documented in CONTRIBUTING.md. This ensures that tests results are reproducible (except for cases like removed/expired GPG key).

phive update is intended to update the tools, and it changes phars.xml.