Currently, we upgrade Deprecation warnings to Fatal Errors.
So to support current version of PHP (8.2), we're basically hunting down all cases of things that are deprecated in 8.2, to fix them before we can actually use 8.2.
That kind of defeats the purpose of the PHP team deprecating the errors instead of out-right deleting them - that is, these things are deprecated to give applications (us) time to remove them without breaking anything...
And I'm guessing there will be a bunch more deprecations in the next couple of years from PHP.
OTOH, we can't just keep the warnings in the logs and hope we'll eventually get to them - most people ignore the logs.
My proposal, then:
- Promote "Deprecation" notices into Setup Issues
- Catch the notice, phlog() it anyway, and add it to a Cache entry (PhabricatorSetupCheck is using cache for the heavy checks)
- If any user is running into a Deprecated event, they get to continue their work and an Admin will get the Issue lamp
- In the issue view, we'll show a count of these events, one of the traces, and instructions on how to report them. We'll also explain that these warnings means "Phorge might not be compatible with newer versions of PHP".
- Restarting the server will clear the warnings cache - we can maybe try to keep them in a database for later retrieval, but they'll also be in the logs.
If we do that, we can basically announce that we support PHP 8.2 already - as far as we know, everything should still work, until version 9 where they are slated to become runtime or compile time errors.
This might also gives us a path towards deprecating Phorge API in the future, to promote a more-stable Extension ecosystem.
There are several different execution contexts to handle:
- Scripts in phorge/bin/ and phorge/scripts/
- SSH server-side scripts (ssh-auth and ssh-exec)
- SSH client-side scripts (ssh-connect - I think this one is usually executed from the web context, when a diffusion request is involving a repository that's hosted in another Phorge host)