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…
>
> I am here for a pre-RFC feedback. It’s not coding related, but more about
> convention.
>
> I’m a follower of the french mailing list about php internals where 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 : “What!!!? That should not be done in minor version, but
> go for major!”. (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.doku
>
> tl;dr: If it’s a BC, deprecate in next minor version unless it’s 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 forever)
- 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
