Currently PHP_TARGETS=php-8.2 is still masked in use.stable.mask with "PHP 8.2 is in testing". However, PHP 8.2 is out since December 2022 and it's already midway it's lifetime. https://www.php.net/supported-versions.php PHP 8.2 compiles cleanly and seems stable AFAIK. Perhaps php_targets_php8-2 should be unmasked? Reproducible: Always
I'll probably get to this eventually, but the delay is due to me being the only one maintaining PHP at the moment. And my personal interest in "PHP" doesn't extend far past dev-lang/php. Stabilizing 8.2 and the associated USE flag (php_targets_*) involves a bunch of extensions as well, and those are all currently unmaintained. To ensure that the flag changes don't break anything, we need at the very least a github PR that will trigger a full CI run.
Understandable — and kudos for doing that single-handedly! The CI run sounds sensible, but I wouldn't know where to start — my knowledge of portage inner-works and is pretty superficial, so I'm not of much help. Plus, like you, my interest is mainly on PHP itself and only a couple of extensions. I suspect that's the most common scenario. With that — and I apologize if this makes no sense at all —, this means that perhaps not so used extensions are blocking PHP 8.2 which is what most need: would it make sense (assuming this is feasible) to stabilise PHP 8.2, while not updating the extensions to support php8-3 (USE_PHP="php8-0 php8-1"), and leave the test task to those who actually use them?
(In reply to mentalstring from comment #2) > > With that — and I apologize if this makes no sense at all —, this means that > perhaps not so used extensions are blocking PHP 8.2 which is what most need: > would it make sense (assuming this is feasible) to stabilise PHP 8.2, while > not updating the extensions to support php8-3 (USE_PHP="php8-0 php8-1"), and > leave the test task to those who actually use them? Here's the catch: I don't know :) The last time I did it myself was when we moved from php-5.4 to php-7.0. Another developer handled every transition since then, and my memory isn't that good. It's possible (maybe even likely) that something breaks by stabilizing only dev-lang/php:8.2 without the corresponding PHP_TARGETS. The best way to detect it would be to submit a PR on github -- that will automatically trigger a CI run that sanity checks every package in the tree. But at that point we might as well stabilize the PHP_TARGETS, too, and let the CI detect any issues with the whole thing. It's really not that much work, a few hours at most. It's just one of the least pressing problems I have right now. If anyone else wants to take a shot at it, please consider it open season.
After looking into this, I believe what should happen is 1. unmask PHP 8.2 (See https://github.com/gentoo/gentoo/pull/34967) 2. Add USE_PHP="… php8-2" to packages that do not have it yet 3. stabilize PHP 8.2 (bug #920701) So this bug (unmasking PHP 8.2) is blocking bug #920701. I don't see a reason why we should not make the first step and unmask PHP 8.2 now. @mjo: as last remaining member of the PHP team, please correct me if I am wrong.
