Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120302
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_06E4DC32-ADB9-4201-A2E6-06013FC3F35E"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\))
Date: Mon, 15 May 2023 20:11:56 +0100
References: <CAH5C8xXtCVHaxwzmAW_eBxp_D6p7kww9svND=3AEeC9X6--YXg@mail.gmail.com>
 <ffa8138a-f1b6-3926-bc2f-558ffca344b0@gmail.com>
 <CAH5C8xXhCkZt7bBs7YcjMBRYM5ggu7W47huCCbVwb2-q_zFnBA@mail.gmail.com>
 <e3eba528-a015-48be-ba8e-fa71d512aa33@app.fastmail.com>
 <CAH5C8xVJPXx8Mk5WViOiqBe-094zTbtSO6pkZGx2BeGKbaXVoA@mail.gmail.com>
 <9ab0173f-a6f2-66f6-3ab3-d5f0c44feb05@bastelstu.be>
 <CA+kxMuT_DsqqH6-pq+P7ZjddEpCetHhYQvuDkAd4_oNSh7ePpA@mail.gmail.com>
 <D222D279-03C2-413A-A65A-67EA96EFBF88@gmail.com>
 <CAH5C8xXFTuL9Eno6FTnMqzF084NiPY-iDSebRwwxu2Dc3=tr1A@mail.gmail.com>
 <9F928894-199E-4C46-A590-136BDDE035F7@gmail.com>
 <68c1b984-1bcd-4dfd-8499-65fe392d7783@app.fastmail.com>
 <CAFPFaM+pjKwCfV8aUM6pd1XJRXc_n9hRq+ZdUxxU06fcqsPOkQ@mail.gmail.com>
 <731143A6-D1A2-47E1-B878-8F4C5906139C@gmail.com>
 <bb41d0ab-6a5f-47d5-87e5-97c2ab36ec99@app.fastmail.com>
 <99B8DE78-5D72-4B37-8C5F-E173B764459A@gmail.com>
To: php internals <internals@lists.php.net>
In-Reply-To: <99B8DE78-5D72-4B37-8C5F-E173B764459A@gmail.com>
Message-ID: <7A80D1FC-5A5B-4CAA-824A-53E8BE00C702@sewell.info>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded
 signatures
From: php@sewell.info (Matthew Sewell)

--Apple-Mail=_06E4DC32-ADB9-4201-A2E6-06013FC3F35E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On 15 May 2023, at 19:51, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> On 15 May 2023 19:38:56 BST, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
>> I agree entirely.  Setting reasonable expectations for users to plan =
around, such as a known 5-years-per-major cycle, helps end users far =
more than "whelp, we did something big, version number time!"
>=20
>> Tangent: If I were to put together an RFC that set out such a 5 year =
cycle expectation with reasonable guidelines around when things could be =
deprecated, would anyone actually support it?
>=20
> A big yes from me, but I've not had the most promising responses when =
banging that drum in the past.
>=20

Hi,

As an end user this would be very useful and address a lot of queries =
when planning and budgeting for PHP developments, especially if major =
breaking changes were also in .0 versions as I saw suggested elsewhere =
in a recent thread (also from Larry I think).

I've been spending a lot of time reading around and thinking after the =
"Future Stability of PHP Thread" last month and think that this level of =
predictability would do a lot to mitigate issues (though appreciate it =
would have other consequences).

Best wishes,

Matt=20


--Apple-Mail=_06E4DC32-ADB9-4201-A2E6-06013FC3F35E--