Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95441
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAC0n1EC8=+gnbqn+R_Z8YFVi=XGT4d+FGk2NU+6_Tsv1-O8+eg@mail.gmail.com>
References: <CAC0n1EC8=+gnbqn+R_Z8YFVi=XGT4d+FGk2NU+6_Tsv1-O8+eg@mail.gmail.com>
Date: Thu, 25 Aug 2016 16:00:51 +0900
Message-ID: <CAGa2bXZrKg4-YjNkBHwTrUv6Rh3ENMvgBsk4g94hTOWo1XVeRQ@mail.gmail.com>
To: Rodrigue Villetard <rodrigue.villetard@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Write down a deprecation policy
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Rodrigue,

On Fri, Aug 19, 2016 at 10:45 PM, Rodrigue Villetard
<rodrigue.villetard@gmail.com> wrote:
> First post here, so please be gentle and pedagogic with me if I am
> misbehaviouring=E2=80=A6
>
> I am here for a pre-RFC feedback. It=E2=80=99s not coding related, but mo=
re about
> convention.
>
> I=E2=80=99m a follower of the french mailing list about php internals whe=
re we
> discuss, chiefly thanks to Pascal Martin, where does the french php
> community stand regarding RFC.
>
> Now and then, debates about RFC on the mailing list are polluted by this
> simple argument : =E2=80=9CWhat!!!? That should not be done in minor vers=
ion, but
> go for major!=E2=80=9D. (recently, it was triggered by this one:
> https://wiki.php.net/rfc/remove_utf_8_decode_encode)
>
> With some pals of this mailing list, we came to wrote this draft of RFC:
>
> objective : Write and follow a deprecation convention for PHP
> draft : https://github.com/gorghoa/the-deprecated-rfc/blob/master/RFC.dok=
u
>
> tl;dr:  If it=E2=80=99s a BC, deprecate in next minor version unless it=
=E2=80=99s security
> related
>
> May we have your feedback on such proposal? Is it the right place to
> discuss it?

+1 for having a general guideline for depreciation and removal.

Although I'm radical about utf8_decode/encode deprecation to get more
attentions/opinions for utf8_encode/decode removal,  I think following
procedure would be good for a feature removal.

 - Document deprecation to the manual at any time. (Feature may be kept for=
ever)
 - Raise E_DEPRECATED error on next major version. (If it should be
removed in the future)
 - Remove deprecated feature on next major version. (Remove it if it
should be removed)

So if we decide to remove something now, actual removal will be PHP 9.

P.S. utf8_decode/encode are "Shouldn't use functions" as they make
code non I18N needlessly. According to the code, original author's
intention was to implement various encoding support. I guess this
wouldn't happen anymore.

--
Yasuo Ohgaki
yohgaki@ohgaki.net