The setup-php action runner offers the nightly alias for the PHP "dev" version. By using that alias instead of the hard-coded version number for PHP "next", the manual maintenance needed for the workflows is decreased and made less error-prone.
This also fixes the current "error" that the conditions for the "composer install" step still referenced PHP 8.3 instead of PHP 8.4.
There is a small down-side to this change. To explain this, we need to understand the PHP release cycle.
Most years, a new PHP version is released towards end of November/beginning of December.
However, the branch for the new PHP minor/major is cut before the first RC, which - in the current release process - means towards end of September.
From that moment onward, the "dev" version (master branch) of PHP already becomes the "new + 0.1" version.
What this means for the workflows is as follows:
With a hard-coded "next" PHP version, the tests are run against that exact version until the workflow is manually changed.
Using "nightly", the tests are run against PHP-next between December - September, but against PHP-next+1 in October and November.
So the practical implications are that the "updating the workflow for the newly released PHP version" task, which is normally executed round the time of the release of a new PHP version, should be moved forward to the time when the first RC of the new PHP version is cut.
As this is a tool used in CI of other projects, officially supporting a new PHP version early, makes sense though, so this "early" update of the workflows for a new PHP version also makes sense.
coverage: 96.408%. remained the same
when pulling 3496c576e37bc0b561e0dc4ac176d511a4c6e61f on feature/1.x-ghactions-use-nightly-for-php-next
into f3a7fbdb42918f2edc170f51be6cf5dda40032ed on 1.x.
The setup-php action runner offers the
nightly
alias for the PHP "dev" version. By using that alias instead of the hard-coded version number for PHP "next", the manual maintenance needed for the workflows is decreased and made less error-prone.This also fixes the current "error" that the conditions for the "composer install" step still referenced PHP 8.3 instead of PHP 8.4.
There is a small down-side to this change. To explain this, we need to understand the PHP release cycle.
master
branch) of PHP already becomes the "new + 0.1" version.What this means for the workflows is as follows:
So the practical implications are that the "updating the workflow for the newly released PHP version" task, which is normally executed round the time of the release of a new PHP version, should be moved forward to the time when the first RC of the new PHP version is cut.
As this is a tool used in CI of other projects, officially supporting a new PHP version early, makes sense though, so this "early" update of the workflows for a new PHP version also makes sense.