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

Hi,

Hello everyone,

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?

The release process RFC does not allow BC breaks but in edge cases where it is absolutely required. The utf8 proposal does not fit in this definition.

It can be clarified, always good to be more clear.

Cheers
Pierre

Hi,

Thanks Pierre, the release process RFC is indeed a good start.

But, to be more concise, our proposal is, in fact, more about
functionality lifecycle planning than bc break.

I admit I have not been crystal clear about the scope of this proposal
in my first message.

What we would like, is more:

• Explicit remaining time to live of a deprecated feature (ie. in
  which future version of php this deprecated functionality will be
  dropped)
• More ergonomics and normalized deprecations messages

Best regards.

--
Rodrigue Villetard