Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122229
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-119-ga8b98d1bd8-fm-20240108.001-ga8b98d1b
MIME-Version: 1.0
Message-ID: <47253b99-b0b9-4022-8536-9b9f0d2f9070@app.fastmail.com>
In-Reply-To: 
 <CAJp_myUA1O9-9WBoncdQ5EyCPG_q5V5HfpuDXACjTjignpFggQ@mail.gmail.com>
References: 
 <kii8EchCRNKJRI1IgoTQGYbxr2d0_BNN6dm4QrEFnWNaWLaH68cG-GioF5j6ebhIJv5wAVKdHojWk5XJqk9z_yL4cA0Fmb1KD0P19VrCiXU=@gpb.moe>
 <344c3e06-3822-4b20-9a6f-a58fb64929a7@app.fastmail.com>
 <CAJp_myUA1O9-9WBoncdQ5EyCPG_q5V5HfpuDXACjTjignpFggQ@mail.gmail.com>
Date: Mon, 22 Jan 2024 21:44:57 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Jan 22, 2024, at 9:11 PM, Matthew Weier O'Phinney wrote:
> On Mon, Jan 22, 2024 at 12:54=E2=80=AFPM Larry Garfield <larry@garfiel=
dtech.com>
> wrote:
>
>> I am in support of this change.  My only concern is timeline.  This R=
FC
>> would deprecate it in 8.4, and presumably support would be removed in=
 9.0.
>> While we haven't discussed a timeline for 9.0, historically the patte=
rn is
>> every 5 years, which would put 9.0 after 8.4, which means only one ye=
ar of
>> deprecation notices for this change.
>>
>
> This is... not true. There is literally no established pattern for when
> major releases take place, either by length of time, or number of minor
> releases.
>
> PHP 3 had no minor releases. PHP 4 had 4 minor releases before PHP 5
> dropped, and then a minor release happened AFTER PHP 5 was already in =
the
> wild (4.4). PHP 5 had 7 minor releases, with MULTIPLE YEARS between so=
me of
> the minor releases before the current process was adopted towards the =
end
> of its lifecycle.
>
> We are moving TOWARDS a fairly standard process, but there's no defini=
te
> plans for PHP 9 to follow after 8.4 as of yet, and the process does not
> require it.

I know there's no official statement regarding timeline.  However, 5.3 (=
aka PHP 6) -> PHP 7 was 5 years.  PHP 7 -> PHP 8 was 5 years.  It's not =
unreasonable for folks to assume 9 comes 5 years after 8, whether that's=
 the intention or not.  Given the lengths of time involved there's not a=
 great many data points to work from, but humans gonna pattern match. :-)

In any case, my core point is a deprecation of this impact probably need=
s more than a year's lead time before it's actually removed.  If we agre=
e on that, we should plan around that and actually, you know, plan.

>> Given the massive amount of code that built up between 5.1 and 7.1, a=
nd
>> 7.1 and today, I worry that a year won't be enough time for legacy co=
de to
>> clean up and it would be another "OMG you broke everything you evil
>> Internals <expletive deleted>!" like the "undefined is now warning" c=
hanges
>> in 8.0.  (In both cases, well-written code any time from the past dec=
ade
>> has no issue but well-written code is seemingly the minority.)
>>
>
> But I DO agree with the above. So this might be a time for us to start
> discussing if/when we want a PHP 9 to occur.

--Larry Garfield