I'm thinking of deprecating the pear.phing.info channel and not release 3.x as a PEAR package.
Right now we're already depending on a few composer packages (symfony/yaml, for example), this poses an issue when generating a PEAR package.
Do it: even installing PEAR on any machine is a bigger fuss than anything else
I agree with @Ocramius, @mrook do have an idea how many installations are made by pear ?
I would deprecate the pear channel.
Our logs show ~7000 downloads from our PEAR channel the past 14 days. Compare that to 140.000 downloads from packagist the past 30 days, roughly 4.5k average daily downloads.
Note that PHPUnit also disabled their PEAR channel (eons ago). I fail to see how a deployment/build strategy can work without proper testing as part of it, so they are most probably very old systems that keep crunching and working by sheer luck
@Ocramius yes, I see a fair amount of downloads for older versions in our logs. Probably old systems.
Then you have a very simple solution: stop doing new releases on PEAR, and keep the channel as static contents only, never to be touched again.
Which is precisely what I suggested ;-)
Honestly, phpunit no longer pushing updates via a PEAR channel can prove to be a pain in the ass on older machines so I'm not sure I'd call that a good example to follow.
PHP_CodeSniffer still pushes new versions to [the main] PEAR channel, if you're looking for a counter-example.
@kenguest PHP_CodeSniffer requires no external dependencies (other than extensions). At this point we do.
We could do something similar to phpDocumentor (packing the vendor tree inside the PEAR package) but this doesn't seem worth the effort, or useful.
👍 for new releases via Composer only but keeping a "frozen" PEAR channel.
BTW, any news on the 3.x schedule?
@mpdude thanks for your input! No firm schedule yet, we can discuss that on Slack perhaps.
Refs #657 - remove PEAR building and installation instructions
The PEAR channel has been deprecated.