Re: [RFC] Deprecations for PHP 8.6

On 25 June 2026 10:17:38 BST, "Tim Düsterhus" <tim@bastelstu.be> wrote: > If it turns out that we missed something during the proposal - e.g. by issues being filed in > the tracker, the deprecation can still be reversed and the functionality not actually changed or > removed. Yes, we will inevitably miss things, and spot them later. A proposal might even account for that by proposing an extra long deprecation period to capture more information. (If we are going to regularly do that, we probably need to keep a register of what we intend to remove when - when 9.0 comes around, I fully expect a large amount of deprecated features to be removed with no further discussion.) >We have a diverse set of voters, many of them with multi-year experience with PHP, Open Source, >different employers or clients in case of agencies. I believe that they will be capable of judging >the impact appropriately. And yes, people might point out things in discussion that the proposer missed, that's all part of the process. But neither of those things make it OK for someone to put forward a proposal without making *some* effort to assess the impact. > Any kind of impact analysis performed by the RFC authors can naturally only account for public code (and their own code) and an analysis on Packagist packages, as usually done, completely disregards anything that is not published on Packagist. I think it's still a valuable *first step*, given for many proposals it's pretty easy to do. If there are thousands of public uses, we already know that the impact is likely to be high. If there are a handful of uses, all in a particular context, that can be a clue of *how* people use something. If there are *no* public uses, then we have to do a bit more guesswork, e.g. is it something that's likely to be only in end-user code, so not visible in the check? To me, *all of that* comes under "impact analysis". I totally agree that just putting a number in the RFC isn't all that valuable, but *not even* putting that number in is worse. Regards, Rowan Tommins [IMSoP]