Re: [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
| From: | Yasuo Ohgaki | Date: | Fri, 13 Feb 2015 04:08:56 +0000 |
| Subject: | Re: [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-82576@lists.php.net to get a copy of this message | ||
Hi Pierre,
On Fri, Feb 13, 2015 at 6:36 AM, Pierre Joye <pierre.php@gmail.com> wrote:
> On Fri, Feb 13, 2015 at 3:51 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> > Hi all,
> >
> > On Wed, Feb 11, 2015 at 8:20 PM, Andrey Andreev <narf@devilix.net>
> wrote:
> >
> >> On Wed, Feb 11, 2015 at 12:40 PM, Jordi Boggiano <j.boggiano@seld.be>
> >> wrote:
> >> > On 09/02/2015 22:29, Anatol Belski wrote:
> >> >>
> >> >> ext/imap
> >> >> ext/mcrypt
> >> >> ext/pdo_dblib
> >> >
> >> >
> >> > Sorry if this was suggested already but if those are not maintained
> much
> >> and
> >> > should not be used further ideally, shouldn't we add E_DEPRECATED to
> >> them at
> >> > least?
> >> >
> >> > I understand that they are kept to avoid making the upgrade path
> harsher,
> >> > but it's also not great to let they linger on forever with no notice
> to
> >> > users that they are doing something wrong.
> >> >
> >>
> >> I don't think it has been suggested already, but I agree - should be
> >> deprecated.
> >
> >
> >
> > Vote is vote. Why don't we deprecate them by documentation with obvious
> > warning?
> > We cannot deprecate them immediately, anyway.
> >
> > Is there any objection for deprecation by document?
>
> So we do not want to kill them because they are still used (but dead).
> But we may come with some wrapper to replace almost all the features
> provided by the dead libs? At least for mcrypt, good luck to anyone
> willing to do that for imap ;). But now we should deprecate them but
> deprecation has lost its meaning as we vote on the actual removal,
> which may be rejected.
>
> So basically, unless we clearly have no chance to have a replacement,
> I am totally against adding yet some deprecation notices, not if
> adding a deprecation is actually followed by a removal, read: Vote for
> deprecation means removal in next. But if it is not the case and we
> keep deprecated features forever, then we may just kill the
> deprecation flag instead.
Isn't better to deprecate them in document than nothing?
That's what I thought for now.
I'm looking forward new crypt extension, BTW!
When it is available, we may have vote again.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net