MyIntervals
[TASK] Update the development tools
coverage: 97.079%. remained the same when pulling 77c30d5e30dd701f20b62e35be8aaebcc846cc40 on task/update-dev-tools into 88d7d6fe35f1dc290bfc83fdb0b1c19d292d77c4 on main.
We should probably use ~ version in the PHIVE config, so that contributors don't pick up breaking changes.
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.
Now that the new PHPStan version comes with changes to the baseline, I think we should get this merged.
Though does this also apply to 1.12.13? Are we testing with that version in the CI build?
No, we're only testing with PHPStan 2.x on CI. We only have PHPStan 1.x in the requirements so we can install the Composer packages with lower PHP versions for running the unit tests.
composer-normalizeseems to throw a false error: 'Your Composer dependencies require a PHP version ">= 7.4.0"'.
The message is misleading, since we install composer-normalize via PHIVE. composer-normalize does not follow semver: version 2.21.0 dropped support for PHP 7.3, which is why the error occurs.
Adjusting the require-dev section of composer.json to require PHP >= 7.4 would not be viable, since that would prevent running the unit tests on 7.3. But an explanatory note in the contributing guidlines would probably not go amiss...