In a new post to his site Christian Weiske shares his interaction with the Open Source group at Apple concerning his Structures_Graph PEAR package. While they were interested in the package and its functionality but with one issue.

Fact is that Structures_Graph is used in the PEAR installer, which is shipped as part of OSX's PHP packages. Apple simply wanted to continue their current setup without changing anything

Unfortunately, Apple had issues with the package being under the LGPLv3 license. They had a concern that, in certain circumstances, the license could allow the owner access to other potentially sensitive information from the user. He lists out his options - bascially either changing the license, asking Apple for compensation or just tell them "no". Unfortunately, if they decide that having it under that license isn't acecptable, they may drop PEAR all together (as the package is a part of the installer itself).

As is mentioned in this post to the PEAR blog the server hosting the packages and website has been fully restored as of December 11th and should be 100% functional again.

Our server sponsor eUKhost quickly provided us with a new machine after we told them the old had failed, and the last two weeks were spent setting it up to provide the same functionality as before.

This includes not only the pear.php.net site but also the bug tracker, manual and downloads handling. They share a bit about why it took so long to correct (mostly having to do with technological difficulties with the server provided by the host). While backups did exist, they were only for the packages themselves and XML file structure. Unfortunately this did not include the website and blog database or patch files in the bug tracker. The remainder of the post lists several other smaller things that went wrong in the process, all adding up to plenty of difficulties for Christian as he battled to get the server (and services) back up and running.

In a quick post on the PEAR blog there's an announcement about the release of a version of the tool with full PHP 7 support, version 1.10.0.

After a year of development, PEAR [version 1.10.0](http://pear.php.net/package/PEAR/download/1.10.0) has been released. It works on PHP7 and is [E_DEPRECATED](http://php.net/manual/en/errorfunc.constants.php#errorfunc.constants.errorlevels.e-deprecated-error) and [E_STRICT](http://php.net/manual/en/errorfunc.constants.php#errorfunc.constants.errorlevels.e-strict) compatible.

Apart from those big changes, a number of annoying bugs have been fixed and some features implemented – have a look at the release notes and the roadmap. Thanks to Ferenc Kovacs, Hannes Magnusson, Remi Collet and Ken Guest for their patches.

The post includes the commands you'll need to do to upgrade to this latest version, a simple two-step process of clearing the current cache and performing the upgrade. If you're installing PEAR for the first time, you can follow along with the documentation to get up and running quickly.

As was announced on both the PEAR blog and Christian Weiske's blog, the PEAR project has made a major update to add PHP7 support preparing it for the upcoming major release.

The new PEAR installer release adds PHP 7 support while dropping support for PHP 4 - 5.3. It also fixes a nasty SSL issue that made it hard to use on PHP 5.6. With the update, strict warnings about static calls to a non-static PEAR::isError() are a thing of the past.

I've just published the first preview version: PEAR 1.10.0dev1.

Upgrading your version of the PEAR installer is as simple as a call to pear upgrade specifying this dev1 release (command is included in the post). He also links to some pre-release versions of the go-pear and pear-nozlib installers.

On The PHPcc's site today Sebastian Bergmann, the creator of the popular PHPUnit unit testing framework, shows you how to move to using the tool's phar file and away from the previously used PEAR install method.

In April 2014 I announced that I would shut down pear.phpunit.de on December 31, 2014. The motivation behind this move was to simplify the release process of PHPUnit by getting rid of an outdated distribution channel. I was afraid that I would leave users of my software behind by this move. [...] I am relieved that the shutdown of pear.phpunit.de went as smooth as it did. [...] In this article I show you how to make the transition from using PHPUnit from a PEAR package to using PHPUnit from a PHP Archive or using Composer as easy and convenient as possible.

There's three main steps to the migration from PEAR to the Composer-based phar installation:

• Uninstalling PEAR Packages
• Using PHPUnit from a PHP Archive (PHAR)
• Installing PHPUnit with Composer

He includes the commands and configuration files/settings you'll need to make the transition happen. He also mentions that older versions are still available if there's a need but only on GitHub/Packagist as phar packages, not via PEAR.

In his latest post Phil Sturgeon talks about a project that's been running for a while, the The League of Extraordinary Packages and aims to clear up some recent misconceptions about the group and what they strive for in the projects they endorse.

This is the story of group of friends, who decided to write some code, but somehow confused and angered everyone with a keyboard. [...] Where should I release this code [I was super excited about releasing]? Should I release it with a vendor name of Sturgeon? That seemed rather egotistical. I could make something up, but what is the point of a single vendor with a single package? I wondered if any of my buddies were having this problem. [...] Being as hungover as I was, I thought long and hard, for about 5 seconds until something amazing happened in my brain... The PHP Super Best Friends Club! The guys loved it, and we started making plans immediately.

He goes on to talk about The League and some of the goals of the organization including the stated desire for quality code and a constant stream of work on the project (no abandoned or stale projects). He talks about how some of the rules for inclusion were created and some of the members of the various projects it includes. He then gets to the "recent misunderstanding" part of things with the clash of the League and the PHP-FIG (see here). He clears up some of the confusion in that thread by stating that:

• League != PHPClasses
• League != PEAR

He finishes off the post talking some about the leadership of the group (hint: it's an organization, not really run by a person or persons) and some of the work he's doing to ensure the future of the League and the packages it includes.

If you're a user of the Amazon AWS Web Services SDK software and are using the PEAR channel for installing the tool, you'll need to check out this new post to the AWS blog about its retirement.

There's been a noticeable wave of popular PHP projects recently announcing that they will no longer support PEAR as an installation method. Because the AWS SDK for PHP provides a PEAR channel, we've been very interested in the discussion in the community on PEAR channel support. PEAR has been one of the many ways to install the AWS SDK for PHP since 2010. While it's served us well, better alternatives for installing PHP packages are now available (i.e., Composer) and literally all of the PEAR dependencies of the AWS SDK for PHP are no longer providing updates to their PEAR channels.

He goes through several of the major dependencies the AWS SDK has (like Phirum, PHPUnit and Guzzle) and how they've announced the retirement of their own PEAR channels. Updates to the AWS SDK PEAR channel will cease on September 15th, 2014 but will still be available for downloads of older versions of the library. He also links to the location of the latest Phar and Zip archives if you'd like to use those.

The PEAR blog has posted a new announcement about the latest release of the PEAR PHP package manager, version 1.9.5.

The PEAR installer version 1.9.5 has been released today. The new version – three years after the last stable 1.9.4 and 2 weeks after the preview – is a bugfix only release. 13 bugs have been fixed.

Fixes include things dealing with broken Windows pathing and a change to report the correct php.ini setting for the installed XDebug.

In his latest post Hannes Magnusson describes his "dream" about a future for PHP where things like upgrading and working with extensions would be simpler, faster and more manageable.

Today we will revolutionize PHP. We will make it easier to upgrade the things you care about. We will make it easier to not upgrade things you don't want to upgrade. We will make it easier to distribute your extensions. We will make it easier to release according to your own schedule. We will make it easier to add functionality. We will make it easier to work. Ok, today is a white lie here maybe... I haven't actually implemented this, but bare with me here for a second.

With the introduction and huge growth of Composer, the PEAR package manager is fading in popularity and is slowly being abandoned. Unfortunately, it's still the primary mechanism for deploying and installing PHP extensions (PECL packages). He talks about some of his recent experience reviving a package and issues he had around the use of the packaging manager. He proposes the creation of a new "pecl install" tool - a package manager dedicated to PHP extensions, decoupled from PEAR.

The manager would just install basic PHP then leave it up to you to pick which features you need from there. The idea is still in its early stages, but the idea has taken roots and plans are being worked through to see if this idea will work for the future of the language.

Fabien Potencier has a new post to his site today talking about a recent trend in the PHP community around dependency and package management, the rise of Composer and the fall of PEAR.

As a good package manager to let user easily install plugin/bundles/MODs was probably also a big concern for phpBB, I talked to Nils about this topic during this 2011 hackday in San Francisco. After sharing my thoughts about libzypp, "..., I [Nils] wrote the first lines of what should become Composer a few months later". [...] So, what about PEAR? PEAR served the PHP community for many years, and I think it's time now to make it die.

He goes on to talk about how he personally has used PEAR in the past and when he stopped work on Phirum, a simplified PEAR channel manager. Based on some logging results, he found that most dependencies on his channels were related to PHPUnit's needs. When Sebastian Bergmann announced the move of PHPUnit away from PEAR Fabien decided to make his own move to deprecate and eventually remove new releases from the PEAR sources.