Re: Write down a deprecation policy
| From: | Rodrigue Villetard | Date: | Sat, 20 Aug 2016 08:31:30 +0000 |
| Subject: | Re: Write down a deprecation policy | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-95335@lists.php.net to get a copy of this message | ||
On 20 August 2016 at 07:56, Pierre Joye <pierre.php@gmail.com> wrote:
>
> Hi,
>
> On Aug 19, 2016 8:45 PM, "Rodrigue Villetard" <rodrigue.villetard@gmail.com>
> wrote:
> >
> > 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 : %
> > Uj6https://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