I think that your third point (automated tooling not differentiating) is a bit flawed, and that you have missed out entirely on an entire group of people who are complaining about the changes.
To clarify, the point myself and other library/framework authors are raising is that (a) we DO have robust testing, which (b) DOES notify us of deprecations, but (c) the pace of change means we have churn every year updating our libraries to be forwards compatible with anticipated changes as indicated by said deprecations.
Yes, we could ignore these deprecations. However, there are a few issues. First, not every consumer of our libraries will disable deprection notices, which means we get reports about them. Even if you have a policy that you do not treat deprecations as error conditions that need to be resolved, you end up having to deal with the incoming issues and patches — and the average user doesn't typically search to see if something has been submitted previously. This creates work for the maintainers, as they need to close and cross-link these reports.
Second, many of the new deprecations become fatal errors when strict types is enabled. As such, having PHPUnit not convert deprecations to exceptions doesn't fix anything for libraries that enable strict types; we still end up with new failures in our code when we test against a new PHP version, which, again, leads to work.
My point is that you can have a well-maintained library that chooses to ignore deprecations and still run into churn each year as a new PHP version is rolled out.
For projects with only one or a handful of packages, this is often not terribly onerous. But for those with more (Laminas has more than 160!), it means a substantial time investment — time where we could be dealing with reported issues or adding requested features, but instead are dealing with making our code compatible with a new minor version of PHP — when minor versions are supposed to insulate us from this very sort of problem!
Don't get me wrong: I definitely approve of the majority of changes that are happening to the language. They make it more predictable, easier to work with, and allow me to write more maintainable code. But the fact that each minor release — and don't forget, minor releases are YEARLY — leads to code churn in the libraries I maintain makes me want to give up on producing OSS, because this sort of churn is busy work with very few benefits.
Do I have any ideas on how to make things easier? Not currently. Deprecations DO allow us to adapt our code earlier to upcoming language changes, and waiting 1, 2, 3, or 4 minor versions to address them would likely require far bigger, more time-consuming changes on our part later. It's the pace at which they occur that is hard on the ecosystem.
One thought I've had is to potentially accept deprecations via an RFC, but only apply them in the final minor release of the series. This would allow libraries to address them all at once, and only once every several years. However, I suspect the process to make this happen could be quite difficult/laborious on the PHP internals developers.
Hi Matthew!
I'm curious how that's a good tradeoff. You're suggesting that (for example), dynamic properties be deprecated in 8.2, but not actually throw a deprecation (with or without the supressing attribute) until, say, 8.4, and then in 9.0 they'd error hard without the attribute?
The logistics for Internals aside for the moment, wouldn't that mean for most users they'd suddenly get hit with a massive wall of deprecations all at once? Or is that the idea, that the major library producers just take one year off every few years to deal with deprecations but can ignore them between now and then?
I suppose I can see the point, but we normally tell people to not wait longer to address issues. Would the total time invested be that different? (I really don't know; I'm not even close to being in your shoes.)
Without the deprecation notices, though, people who wanted to get a jump on the process earlier (those of us who have only single-digit libraries to keep track of), wouldn't that make it harder, because the engine isn't pointing out where we need to make updates for us?