Re: [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

php.internals

Tony Marston

9 years ago
Sent: Friday, September 09, 2016 12:55 AM
>To: Tony Marston ; internals@lists.php.net >Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle >Hi! > >> There should be a rule that nothing can be deprecated unless there is a >> viable, stable, fully functioning and fully supported alternative. I do >> not like the way that some people simply say "I do not like this. I do >> not use this. Nobody should be using this. Let's deprecate it" > >You can have any rules you like, but if the original author is not >interested in the tool anymore, the only options you have are: > >1. Support it yourself >2. Pay/beg/bribe/persuade somebody to do it for you >3. Failing that, use it unsupported or switch to another tool > >That's not only how the open source works, that's how everything works - >try to get support for out-of-support commercial software (or >out-of-support hardware for that matter) and see if it's any easier. > >So yes, it is "typical" as you note - as typical as the life can be :) > >That said, if the tool is useful and being used, I completely agree that >we should make effort in keeping it supported. But we should also >account for the possibility of that effort not being successful.
Then I suggest that you take steps to ensure that any drop-in replacement offers all the facilities of the current PEAR/PECL library. Anything less would probably annoy a largenumber of existing users.
-- Tony Marston

Mathieu Rochette

9 years ago
On 09/09/2016 11:01, Tony Marston wrote:
> Sent: Friday, September 09, 2016 12:55 AM >> To: Tony Marston ; internals@lists.php.net >> Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle >> Hi! >> >>> There should be a rule that nothing can be deprecated unless there is a >>> viable, stable, fully functioning and fully supported alternative. I do >>> not like the way that some people simply say "I do not like this. I do >>> not use this. Nobody should be using this. Let's deprecate it" >> You can have any rules you like, but if the original author is not >> interested in the tool anymore, the only options you have are: >> >> 1. Support it yourself >> 2. Pay/beg/bribe/persuade somebody to do it for you >> 3. Failing that, use it unsupported or switch to another tool >> >> That's not only how the open source works, that's how everything works - >> try to get support for out-of-support commercial software (or >> out-of-support hardware for that matter) and see if it's any easier. >> >> So yes, it is "typical" as you note - as typical as the life can be :) >> >> That said, if the tool is useful and being used, I completely agree that >> we should make effort in keeping it supported. But we should also >> account for the possibility of that effort not being successful. > Then I suggest that you take steps to ensure that any drop-in replacement offers all the facilities of the current PEAR/PECL library. Anything less would probably annoy a largenumber of existing users.
PEAR/PECL will still be available and working if the RFC passes. For most users nothing will change at all. It will only change for users installing PEAR/PECL from source along with PHP. They'll have the choice to either manually install PEAR/PECL or use something else. Installing PEAR/PECL is already documented : https://pear.php.net/manual/en/installation.getting.php. This workflow already works. what other steps should be taken ?