Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115360
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
In-Reply-To: <CAF+90c-T0AgThGz5KX8ngv4e4To+cpuJ9vkXTfs8OAngUnO5ew@mail.gmail.com>
Date: Wed, 7 Jul 2021 21:33:57 -0400
Cc: Jakob Givoni <jakob@givoni.dk>,
 php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <2E4D2A97-6E63-4161-ACB1-CA762AFDAD76@newclarity.net>
References: <CAF+90c96J7dyq1KsgoPTndM09V=oj46cXm0SxjfkJXiL3TjdHg@mail.gmail.com>
 <CACwt+JfrMa3h2GfG0cxNFmJeg3mPDzf6QWV44zuz+xYBqUsJfg@mail.gmail.com>
 <1dcefcec-a3e4-e773-4950-b11d377ecc7f@gmail.com>
 <122F660D-DE94-4DFE-A0E9-FEC202E89E3A@newclarity.net>
 <62eb8eff-e671-5b3b-5e25-2a5b38160fcd@gmail.com>
 <D85C91B1-7BFD-4DDD-ABAF-F9604529D7EB@newclarity.net>
 <586591d0-8bbc-a42c-f92b-819b8fc6ac20@gmail.com>
 <CAJmjfvXjQu-n699DkQWwBzRBdm3hjosz6o0Cxwy5AntFOua17A@mail.gmail.com>
 <CAF+90c-T0AgThGz5KX8ngv4e4To+cpuJ9vkXTfs8OAngUnO5ew@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1
From: mike@newclarity.net (Mike Schinkel)

Replying to Rowan and commenting on Nikita's message.

> On Jul 6, 2021, at 4:24 AM, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
>> Instead I replied because your email strongly implied (stated?) that =
"deprecation required removal"
>=20
> I stand by that interpretation, which while not universal is very =
widely used, and I think is more useful than a general hint at "bad =
practice".
>=20
> You spend most of your e-mail seeming to argue against it, and then =
seem to say that actually you do agree with it after all, and all you're =
saying is that sometimes the deprecation period should be longer:


What I was disagreeing with is your assertion that "by definition" =
deprecation must be followed with near-term removal.


> I am not advocating that.  I am advocating we should consider making =
it:
>>=20
>> "features that are strongly discouraged will*probably*  be removed in =
the next major version, but in some cases may be retained for one or =
more major versions."
>=20
> I'm totally OK with that.
>=20
> I do think that there should be a clear *plan* for removing each =
deprecated feature, though. That plan might be "deprecate in 8.1, and =
examine prior to 9.0 whether usage has dropped / the alternatives are =
mature / etc". It might flat out be "deprecate in 8.1, but don't remove =
until 10.0".
>=20
> Otherwise, the message becomes "this feature is kind of bad, and at =
some point we might decide to drop it without further notice, but =
actually we might not, so no hurry to remove it", which I just think =
isn't that helpful.


The "plan" that makes the most sense is one that takes into =
consideration the BC breakage that would occur at the time of removal, =
and that is not something you can project _in advance_.   IMO you cannot =
really know in advance how long a feature might continue to be used in =
the wild in some cases, you can only evaluate the current situation when =
the time comes. =20

Or as they say "no battle plan survives first contact with the enemy" =
and "facts on the ground matter."


> On Jul 6, 2021, at 9:30 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:
>=20
> As far as this RFC is concerned (and this is the customary phrasing =
for all
> deprecation RFCs), all changes are for deprecation in PHP 8.1 and =
removal
> in PHP 9.0. That's the baseline.
>=20
> However, nothing prevents you from starting an RFC prior to the PHP =
9.0
> release that counters the prior decision and extends the deprecation =
period
> for another major version. However, the onus is now on you to argue =
that
> something previously deprecated should not be removed (or not be =
removed
> yet). If you cannot make a strong argument for that, then the default
> action is taken.
>=20
> We do still carry a couple deprecations from PHP 5 times around, =
because
> actually removing the affected functionality has some technical =
issues.

And this is exactly how it should be. That deprecating a feature w/o =
near-term removal is a legitimate approach to have people vote on. IOW, =
that deprecation does not "by definition" require near-term removal.

Removal is determined when appropriate and by vote, and not any =
hard-and-fast "IF deprecated THEN must be removed soon."

Please note that I am fully respecting the ballot and voting outcomes =
here; if people always vote to remove a deprecated feature in next major =
version that so be it. =20

But RFC authors should be allowed to propose a long time horizon for =
removal without being told they "are doing it wrong."

-Mike