Believe it or not, the work of the past year is reaching a critical mass. Just a few minutes ago, I released
PEAR_PackageFileManager version 1.3.0, a new version that has a few nice new features, the most significant being that it actually works with PEAR 1.4.0.
In addition, I completed an important step in work on the PEAR installer itself today...
As of today, the installer is fully ready to handle secure post-install scripts, and is slightly more secure with the update-channels command.
I worked out some logic flow errors in PEAR_Downloader_Package::willDownload() and ::isInstalled() that help to remove redundant XML_RPC calls. In addition, I fixed a flaw in the package.xml version 2.0 validation when <install> or <ignore> tags are present, one that affects PEAR itself.
I also added a ridiculous unit test for the upgrade-all command, and fixed all of the issues with it. The test is ridiculous simply because there are more than 3000 lines of setup code for something like an 11-line test due to all the fake xml-rpc calls that must be simulated.
The unit tests for PEAR pass with flying colors on both windows and linux, and now that the frontends for the web, cli, and gtk all work with PEAR 1.4.0, I am going to focus my attention on the next things:
- Separating pear installation from pecl installation (new pecl script)
This will fix issues people have with the -n switch to PHP disabling extensions, so that extension dependencies fail, and also the problem of enabling it, which then no longer allows upgrades to existing extensions without a restart of PHP. I've also had no bites from pecl devs who want to test the new package.xml stuff, I guess we'll hear from them when 1.4.0a1 comes out

. Support for binary packages of PECL extensions is built into this release, hopefully PECL developers will take full advantage of this to allow our underprivileged windows-based friends to install pecl extensions without digging through snaps.php.net.
- Beginning the long road to implementing channels on the server side
This one speaks for itself - we need a channel server that folks can use before the client can really take advantage of it. I have been doing some private experimentation with a REST-based system of package information that will also have the benefit of working with a static server (no php, no mysql needed, just ftp upload) for small channels. A package can be created that simply uploads static xml snippets based on a release. Also, my multi-user, driver-based PEAR_Server code will work for larger sites that approach the complexity of Horde. Also, Demian Turner has begun experimenting with modifying the existing pearweb code to support another channel, which is surprisingly not that complicated once you get the dang thing running.
- Documenting absolutely everything
This will take eons, but someone needs to at least start it. I tend to be overly verbose in my descriptions (anybody reading this surprised ), so I will do the basic docs, but I expect all of you to dive in and correct my grammar, suggest improvements. I promise to relinquish my ego with regards to my writing.