On Thu, Sep 20, 2018 at 7:02 PM Stanislav Malyshev <smalys...@gmail.com> wrote:
> Hi! > > > We have deprecated and moved to PECL a number of extensions in the > > recent past. These were mysql and ereg in PHP 7.0 and mcrypt in PHP 7.2. > > I have always understood these moves as "sunsetting" the extensions, in > > the sense of strongly discouraging their continued use, as well as > > removing any promise of further maintenance. The move to PECL rather > > than outright deletion of the code is just a matter of general policy > > (or so I thought). > > I think we should distinguish between the two cases - not having > extension in core and deprecating the extension. Unless we declare that > the only function of PECL now is to serve as a graveyard for archival of > deprecated code. I don't think we really want to do that? If yes, than > we should distinguish between deprecating the extension and just moving > it to PECL. > Sure, generally speaking we can also move an extension to PECL without deprecation -- for example if it does not appear to be commonly used anymore and we do not want to maintain it in php-src, but otherwise nothing is wrong with the extension and its use. However, this is not the case for the last three moves to PECL we did. In those cases we always wanted to explicitly discourage further use of the extension. The same is true for ext/wddx. It's not just a matter of nobody using WDDX in 2018, we also have specific security concerns which make continued use of this extension dangerous. If your code breaks because we dropped ext/wddx, you should not be able to type "pecl install wddx" and go back to ignoring the issue. By the way, I'm fine with moving the extension to PECL already in PHP 7.4, the part that's important to me is that it's going to generate some form of diagnostics once in PECL. Nikita
