On Mon, Apr 10, 2023 at 3:59 PM Craig Francis <cr...@craigfrancis.co.uk> wrote:
> One team of developers I know are still finding these issues well over a > year later (they also introduce new code that trips it as well); two other > teams specifically ignore this deprecation (far too many instances to > "fix"), and one team is still to decide what they are going to do > (annoyingly they are still using 7.4). How can they be finding those issues over a year later? Do they have pieces of completely untested code that has never been called in more than a year? If so, they have bigger problems than PHP deprecations. Otherwise, they should see the deprecation logs either on production or on CI. I highly doubt they're not collecting any logs from production, so they had more than a year to collect all the places where a deprecation is triggered and fix them. Speaking of those that ignore them, well, I'm not sure what the expectation is. Do they think the deprecation will simply go away on itself? Or do they expect the already small PHP team to infinitely support their code, sacrificing other developers' experience? Also, can you name an actively developed software product that introduced no breaking changes in the span of the expected 10 years? Besides, as mentioned before, it's likely that such projects are also using at least some other 3rd party PHP dependencies, and those usually have a shorter BC lifespan than PHP and require more efforts to keep them up-to-date. Again, is the expectation here to infinitely keep the backwards-compatibility? If so, why is it that almost every dependency follows Semver specifically to manage breaking changes, and there are practically no examples of actually avoiding breaking changes in the long term?
