Change Details

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. Thoughts? ---------- There are several different execution contexts to handle: - Web - Arcanist - Daemons - Scripts in `phorge/bin/` and `phorge/scripts/` - SSH server-side scripts

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. Thoughts? ---------- There are several different execution contexts to handle: - Web - Arcanist - Daemons - Scripts in `phorge/bin/` and `phorge/scripts/` - SSH server-side scripts (ssh-auth and ssh-exec) - SSH client-side scripts (ssh-connect)

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. Thoughts? ---------- There are several different execution contexts to handle: - Web - Arcanist - Daemons - Scripts in `phorge/bin/` and `phorge/scripts/` - SSH server-side scripts (ssh-auth and ssh-exec) - SSH client-side scripts (ssh-connect)