Re: Write down a deprecation policy

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