On 20 August 2016 at 07:56, Pierre Joye <pierre....@gmail.com> wrote: > > Hi, > > On Aug 19, 2016 8:45 PM, "Rodrigue Villetard" <rodrigue.villet...@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 : 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
