On Thu, Jun 25, 2026, at 5:38 AM, Rowan Tommins [IMSoP] wrote: > 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]
I agree with Rowan and Juliette here. "Seems no one on Packagist is using this" is a useful datapoint. It is not the complete picture, it is not the only data point, and it is not the last word on the subject, but that doesn't make it un-useful. It is just useful-in-context. If other data points are available, great, include them too. The alternative is essentially "let's make a one-sided argument for deprecating something, then see who yells at us loudly in December and writes blog posts about how PHP Internals doesn't care about backward compatibility" Which... is bad press we really don't need, yet again. We can make at least a token effort to minimizing the disruption of deprecations, can't we? --Larry Garfield
