Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120296
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-415-gf2b17fe6c3-fm-20230503.001-gf2b17fe6
Mime-Version: 1.0
Message-ID: <bb41d0ab-6a5f-47d5-87e5-97c2ab36ec99@app.fastmail.com>
In-Reply-To: <731143A6-D1A2-47E1-B878-8F4C5906139C@gmail.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>
Date: Mon, 15 May 2023 18:38:56 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded
 signatures
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, May 15, 2023, at 6:36 PM, Rowan Tommins wrote:
> On 15 May 2023 09:54:41 BST, "G. P. B." <george.banyard@gmail.com> wrote:
>
>>Why are we assuming that PHP 9.0 is going to come after PHP 8.4?
>
> Historically, PHP has had a major release roughly every five years. The 
> main exception is PHP 6, which was never released - but whose major 
> features became PHP 5.3, five years after 5.0, and six before 7.0
>
> I think planning a rough timeline is more useful to users and 
> contributors than waiting until there's some exciting headline feature. 
> Otherwise, it becomes tempting to sneak in breaking changes in 8.x 
> because "we don't know how soon 9.0 is", or to have a rush of changes 
> because "we've only just decided 9.0 is soon".
>
> It also helps avoid putting a release number on an experimental feature 
> that might never arrive, as with Unicode strings in 6.0; or that might 
> turn out to be less important to most users than other changes, like 
> the JIT in 8.0.

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!"

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?

--Larry Garfield