Today I wanted to find out if the version of Symfony I was using (the latest LTS v4.4.30) supported PHP 8 or not.

Asking in Slack, I was pointed at various pieces of documentation which specified "PHP 7.1 or higher". The documentation page did not appear to include a last modified date, so it was unclear to me (given Symfony 4.4 was, I believe, released prior to PHP 8.0) if this was meant to include major version 8. I was also pointed at the symfony/symfony composer.json file which included a constraint suggesting Symfony would work on PHP version 7.1.3 and all future versions.

This is not a promise that anyone in software development can really make. I have no idea what will be deprecated and removed in the next major PHP v9/10/11/12/13/14. Nobody can say for certain what breaking changes new major versions will entail. Presumably next year Symfony v4.4.30 will drop out of support anyway - at which point I assume no work will be undertaken to upgrade the maximum supported version of PHP? Will the version constraint be updated at the point of EOL to say the highest version it works with? As far as I can see that never happened for Symfony v2.0 which still strictly suggests, from the PHP version constraint, that it supports PHP 8 - despite being out of support and not touched since 2013.

For the sake of clarity, I'd argue that if Symfony has been tested and verified with certain versions the composer.json file should say so explicitly: something like ~7.0|~8.0. When new versions have been tested against each maintained version, the constraint should be updated. Ideally each version would also document somewhere the minimum and maximum version of PHP that it works with on the user-facing website (I couldn't find this anywhere, I had to guess based on how the GitHub Actions CI was set-up) - ideally on e.g. https://symfony.com/releases/4.4.

See also: https://getcomposer.org/doc/faqs/why-are-unbound-version-constraints-a-bad-idea.md - for discussion on why this is an antipattern for library dependencies.