Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120307
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>
In-Reply-To: <731143A6-D1A2-47E1-B878-8F4C5906139C@gmail.com>
Date: Tue, 16 May 2023 12:03:24 +0100
Message-ID: <CAFPFaMLv2qwZhcsfMTfVrGgCj4DeCwnwVM6AOuEq8xmR4upoGw@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000e5a18f05fbcd858c"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
From: george.banyard@gmail.com ("G. P. B.")

--000000000000e5a18f05fbcd858c
Content-Type: text/plain; charset="UTF-8"

On Mon, 15 May 2023 at 19:36, Rowan Tommins <rowan.collins@gmail.com> 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 totally agree that we shouldn't use a major number as an exciting feature
flag.
However, if what we want is a consistent timeline for how long something
gets deprecated before being removed, then let's just do like Python and
state that the deprecation exists for two consecutive releases and will be
removed in the third one.

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).
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.
This, IMHO, is terrible for the project's maintenance. As this basically
says to someone who wants to start contributing to the project by
deprecating some weird behaviour that they may be told off with "you should
have done this X years ago" or "wait another Y years".
People cannot magically know when they should shove aside any other
priorities in life just to be able to make *some* change to the language.
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".
Those sorts of statements alienate new (and old) contributors, and looking
at the state of the projects where we are still very much thin on
maintainers, anything that does this is from my POV a no-go.

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.
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.

Best regards,

George P. Banyard

--000000000000e5a18f05fbcd858c--