PEAR 1.4.x branch is settling into comfortable stability

I'm happy to report that the PEAR 1.4.x branch is finally settling in. All of the issues reported since the release of PEAR 1.4.6 have been rare edge cases that won't affect the greater majority of users. I give the unit test suite that I've been slaving over full credit for this accomplishment, as it has caught several re-introduced problems when fixing newly discovered bugs. If you aren't unit-testing, you are wasting your future time, not to mention your end-users' time!

Since the release of PEAR 1.4.6, several improbably rare issues have been discovered and fixed in PEAR:

• version 1.0.0rc1 is considered to be newer than version 1.0.0 - but 1.0.0RC1 is considered to be older than 1.0.0 because of the way version_compare() works. lower-case rc is now prevented in a version number to prevent this odd edge case.\
• several issues with serializing PEAR_PackageFile_v2 objects were discovered (something the PEAR installer never does) and were fixed, as well as several other edge cases that only affect PEAR_PackageFileManager-based package.xml creation scripts
• the rarely used fanatic command "pear download-all" was failling
• if your script uses System::mktemp(), but never actually instantiates an object descended from PEAR (i.e. no PEAR_Error, no nuttin'), the shutdown function was not registered to clean up temp files.
• --installroot fails for pecl packages
• the "pear" command was not ignoring safe_mode and open_basedir
• the combination command "pear install --packagingroot=blah --offline <packagename>" was failing with an unnecessary error message
• post-install script validation fails with a bewildering error message if you have the tokenizer extension disabled (it is enabled by default)
• upgrading from a channel containing a path (like pear.php.net/subchannel) would fail
• after running "pear install --register-only <packagename>", "pear list-files <packagename>" would emit a bunch of errors. --register-only does not install anything, it only adds a package and its files to the registry. Don't try this one at home kids, unless your registry is screwed up.
• the helpful "optional feature 'blah' available, use "pear install package#blah"" message was not using the channel name - picky picky!

As you can see, all of these are rarely used options for the majority of users, although the --packagingroot bug directly affects people like gentoo, who distribute PEAR packages by using the PEAR installer to install them directly.

Fortunately, there is also a new feature for all you PHPUnit users out there. If you provide an AllTests.php file in the top-level of your tests directory, you can run the tests after installing via:

pear run-tests -p Packagename

This can be used to instruct your users to run the tests if they find a bug that appears to be system-dependent, and makes it far easier to deal with.

Assuming the bugs are fixed, we should see a release of PEAR 1.4.7 within the next two weeks, but don't hold me to that one. We will only release when it is ready to go.

On a personal note, after having devoted a substantial amount of my programming energy and creative impulse to realizing this new conception of what an installer should be and what it should do, I'm quite pleased. The adoption rate is also quite pleasing. 98.349913% of all PEAR installer requests to pear.php.net in the past couple of weeks have been of PEAR version 1.4.1 or newer. This is up from 96.500840% reported just 2 months ago, a promising sign that people are not just installing the package, but finding success in using it. I look forward to the day when this climbs up to the full 100%!

If you haven't upgraded, what are you waiting for