Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120314
Date: Tue, 16 May 2023 09:26:23 -0500
To: internals@lists.php.net
User-Agent: K-9 Mail for Android
In-Reply-To: <bb41d0ab-6a5f-47d5-87e5-97c2ab36ec99@app.fastmail.com>
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>
Message-ID: <2B7287AB-7619-4066-B136-386FAD76E3E0@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: =?US-ASCII?Q?Re=3A_=5BPHP-DEV=5D_=5BRFC=5D_=5BDiscussion=5D_Deprec?= =?US-ASCII?Q?ate_functions_with_overloaded_signatures?=
From: derick@php.net (Derick Rethans)

On 15 May 2023 13:38:56 GMT-05:00, Larry Garfield <larry@garfieldtech=2Ecom=
> wrote:
>On Mon, May 15, 2023, at 6:36 PM, Rowan Tommins wrote:
>> On 15 May 2023 09:54:41 BST, "G=2E P=2E B=2E" <george=2Ebanyard@gmail=
=2Ecom> wrote:
>>
>>>Why are we assuming that PHP 9=2E0 is going to come after PHP 8=2E4?
>>
>> Historically, PHP has had a major release roughly every five years=2E T=
he=20
>> main exception is PHP 6, which was never released - but whose major=20
>> features became PHP 5=2E3, five years after 5=2E0, and six before 7=2E0
>>
>> I think planning a rough timeline is more useful to users and=20
>> contributors than waiting until there's some exciting headline feature=
=2E=20
>> Otherwise, it becomes tempting to sneak in breaking changes in 8=2Ex=20
>> because "we don't know how soon 9=2E0 is", or to have a rush of changes=
=20
>> because "we've only just decided 9=2E0 is soon"=2E
>>
>> It also helps avoid putting a release number on an experimental feature=
=20
>> that might never arrive, as with Unicode strings in 6=2E0; or that migh=
t=20
>> turn out to be less important to most users than other changes, like=20
>> the JIT in 8=2E0=2E
>
>I agree entirely=2E  Setting reasonable expectations for users to plan ar=
ound, such as a known 5-years-per-major cycle, helps end users far more tha=
n "whelp, we did something big, version number time!"
>
>Tangent: If I were to put together an RFC that set out such a 5 year cycl=
e expectation with reasonable guidelines around when things could be deprec=
ated, would anyone actually support it?
>
>--Larry Garfield
>

I would=2E With some remarks=2E=20

I think that having a 5 year cycle for major releases is beneficial=2E

First to users as they know when all the deprecations are being rolled up =
into behavioural changes and (potential) breakage=2E

But also to us, as maintainers, as it could signal *when* it makes sense t=
o work on deprecations, behaviour changes, and code refactoring (that's mor=
e likely to break APIs and extensions)=2E

IMO it would make sense to tweak what sort of user land deprecations can b=
e done in the =2E3 and =2E4 releases (probably being more strict) compared =
to the =2E1-=2E2 releases=2E We'd want to enlarge thr time frame for signif=
icant changes more ahead of time compared to more minor ones=2E

But I do think we ought to be weary of making these rules, in when to allo=
w to deprecate what, too strict=2E A rough set of guidelines makes IMO more=
 sense=2E

cheers
Derick