Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120309
MIME-Version: 1.0
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> <CAFPFaMLv2qwZhcsfMTfVrGgCj4DeCwnwVM6AOuEq8xmR4upoGw@mail.gmail.com>
In-Reply-To: <CAFPFaMLv2qwZhcsfMTfVrGgCj4DeCwnwVM6AOuEq8xmR4upoGw@mail.gmail.com>
Date: Tue, 16 May 2023 13:12:29 +0100
Message-ID: <CALKiJKowEqMG1qkbFLQjLk3qM3Ea=tex7x25mfY=27nWgq37WA@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000f8cc5605fbce7c24"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
From: rowan.collins@gmail.com (Rowan Tommins)

--000000000000f8cc5605fbce7c24
Content-Type: text/plain; charset="UTF-8"

On Tue, 16 May 2023 at 12:03, G. P. B. <george.banyard@gmail.com> wrote:

>
> Because this proposal of "let's do majors every 5 years" now reduces what
> we can do, as we cannot (or should not) deprecate stuff in X.0, as it makes
> it harder for people to upgrade to the new major (see how we postponed the
> 8.0 deprecation RFC to 8.1 after various comments).
>


Again, the solution to "people don't like deprecation messages" is not
"don't deprecate things", it's "improve how deprecation messages work".

There should be absolutely zero reason not to deprecate something in an X.0
release, or even in an X.0.15 release, because a deprecation message form
the code should serve the same purpose as, and have similar impact to, a
note in the documentation.



> But apparently we cannot deprecate anything in X.3 or X.4 because there
> will "never" be a X.5 again and this is "too short" of a time frame.
>


I don't think that's what anyone's saying. They're saying that if we have a
predictable release cycle, we can decide for each case between a
one-to-two-year deprecation, and a five-to-six-year deprecation.

If we don't have any idea when PHP 9.0 will come out, then we can't even
begin to discuss that, we have to say "the deprecation period will last
anywhere between one year and ten years, depending when we get round to a
major release". I don't think that helps anybody.



> Considering, this was partially the argument used against Max Kellerman
> with the header changes: "this should have been done for PHP 7.0 or PHP
> 8.0".
>


Having a fixed release cycle actually allows this to be turned around to
something more productive: "we could consider this for PHP 9.0, which will
happen in 2 years time". Without it, all we can say is "we could consider
this for PHP 9.0, but you have to regularly read the internals mailing list
for several years to get a hint of when that might be".

Note that prior to PHP 5.4, we had this same "when things are ready"
approach to tagging *any* release. Since then, we've had an annual release
cycle, which I think has worked well in terms of both contributors and
users being able to plan ahead.


My understanding as to *why* the JIT caused the major bump was because of
> major changes within the Zend Engine, not necessarily the feature in itself.
>


I mentioned JIT, because around this time in the 7.x life cycle, I was
regularly having this same debate, and people used "everyone knows PHP 8
will be whenever the JIT is ready" as though it was more important than any
other planning we might want to do. I disagreed then, and I disagree now.


> And again, the only "good" reason I see for a major bump is something
like converting streams from resources to objects, as this is a massive
shift and has the possibility to cause issues for a lot of codebases.

Given that we changed a whole list of resources to objects in PHP 8.1, it's
clearly not considered that massive a shift to most people
https://www.php.net/manual/en/migration81.incompatible.php#migration81.incompatible.resource2object


Regards,
-- 
Rowan Tommins
[IMSoP]

--000000000000f8cc5605fbce7c24--