Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119864
MIME-Version: 1.0
References: <aa9f0f66-f772-3fc4-4f66-2245930ab089@helionweb.de>
 <CAGBsUrcQWKc+JD2adprcgdqNAKr==McFeoYO3WF3pR2qxgon2g@mail.gmail.com>
 <CAMXcktN64EsoErjbFzdWe+qzM5RVYNR98WO8xcLOYxeYCK=NiA@mail.gmail.com>
 <CADK1yXJMgSrjCahW2_G-C=ye=mBiuWtQAKyJrbFc-W4ODL6fZw@mail.gmail.com>
 <CAGBsUrd=X6d8eZsSjaz+hQYLTCPCHPExhsawWhr8BWD=prEb1Q@mail.gmail.com> <E1957E21-F069-4E78-98F1-DAF14EE3D92E@craigfrancis.co.uk>
In-Reply-To: <E1957E21-F069-4E78-98F1-DAF14EE3D92E@craigfrancis.co.uk>
Reply-To: autaut03@gmail.com
Date: Mon, 10 Apr 2023 19:02:24 +0300
Message-ID: <CABigaAU1BxRbEMHNAOqmWqqF16VMgkV3SmdT2jRQ5s=oYh3=Bg@mail.gmail.com>
To: Craig Francis <craig@craigfrancis.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f0252a05f8fd806a"
Subject: Re: [PHP-DEV] Future stability of PHP?
From: autaut03@gmail.com (Alex Wells)

--000000000000f0252a05f8fd806a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 10, 2023 at 3:59=E2=80=AFPM Craig Francis <craig@craigfrancis.c=
o.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 othe=
r
> 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?

--000000000000f0252a05f8fd806a--