Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95335
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU7VkTJaJOg1LBCoQkOTc1YXHpOuTKouGtXxuBg-oyiR7g@mail.gmail.com>
References: <CAC0n1EC8=+gnbqn+R_Z8YFVi=XGT4d+FGk2NU+6_Tsv1-O8+eg@mail.gmail.com>
 <CAEZPtU431Sa_uRn26xA3GwUk4U0o-k4FXgRbxVtMjHWY4c8NNw@mail.gmail.com>
 <CAEZPtU5Cw71Ta9eWmsYG6u4OPtPY0yCOGESyDw97WG6QOWgOOQ@mail.gmail.com> <CAEZPtU7VkTJaJOg1LBCoQkOTc1YXHpOuTKouGtXxuBg-oyiR7g@mail.gmail.com>
Date: Sat, 20 Aug 2016 10:31:30 +0200
Message-ID: <CAC0n1ECcnokyvV+m115nHtttqx-YBNb8biQ1eFaoubZrw060VQ@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: PHP internals <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: rodrigue.villetard@gmail.com (Rodrigue Villetard)

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.c=
om> wrote:
> >
> > Hello everyone,
> >
> > 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 =
more about
> > convention.
> >
> > I=E2=80=99m a follower of the french mailing list about php internals w=
here 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 thi=
s
> > simple argument : =E2=80=9CWhat!!!? That should not be done in minor ve=
rsion, 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.d=
oku
> >
> > 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?
>
> 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 definitio=
n.
>
> 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.


--=20
Rodrigue Villetard