I have a dream

I am happy to join with you today in what will go down in history as the greatest demonstration for freedom in the history of our nation project.

Today we will revolutionize PHP.
- We will make it easier to upgrade the things you care about[1].
- We will make it easier to not upgrade things you don't want to upgrade[2].
- We will make it easier to distribute your extensions[3].
- We will make it easier to release according to your own schedule[4].
- We will make it easier to add functionality[5].
- We will make it easier to work.


Ok, today is a white lie here maybe... I haven't actually implemented this, but bear with me here for a second.

- Wouldn't it be great if PHP would just be language/syntax things?
- Wouldn't it be great if you could upgrade an extension you use independently from anything else?
- Wouldn't it be great if you could get your hands on the new intl/mysqlnd/MongoDB/curl/whatever features without needing to upgrade PHP and everything else?
- Wouldn't it be great if you could get your hands on new PHP syntax without needing to upgrade intl/mysqlnd/MongoDB/curl/whatever?

What the hell are you talking about?

The PEAR package manager is dying. It has been dying for a while.
Thats not a bad thing, or even sad, it is actually a very good thing.
It has served its purpose and its time to die and let the next thing take over, like dependency managers.

This however leaves PHP extensions in an unfortunate situation. They rely on the PEAR packaging manager, and there currently isn't any alternative.

Recently, during the process of making Windows binaries for PECL extensions available again (e.g. pecl4win, which died in 2008) the issue of licensing came up - some licenses (including the PHP license which many/most PECL extension are licensed under) requires certain paragraphs to be reproduced (generally simply including the LICENSE file).. making distributing binaries a problem.
Detecting what is a license file became a problem since the packaging manager cannot mark a file(s) as the license.. Adding that functionality is trivial, but there is a problem.
There hasn't been a release of the packaging manager since 2011, and a similar change (adding unix manual pages detection) took 2 years to be merged (and still isn't released!) - but there most likely won't be any release in the near future anyway... And we are stuck.

Now we have the chance to make it right!

I would like to create the new "pecl install" tool, a new extension manager -- a PHP manager.
A way for you to decide what you want to upgrade - do you want bugfixes or new features at the language level, or is there just one specific bugfix or a feature you need from a specific functionality (i.e. extension)?

This tool would effectively only install PHP - the language - not any "default extensions". Then its up to you to decide what you want or need for your project.
You'll get the language version you decide, and you can upgrade the extension set independently of what language version you want to use.

Currently, if you download PHP from source and compile it with its "default extension set" you'll get all sorts of extensions that may or may not be useful to you. If you then install PHP on Windows you get a different set of enabled by default extensions. God bless if you install PHP on a Linux distribution from their packaging repositories, you'll get whatever they decide is best for you.

What about my hosting situation?

Whatever extensions are available won't change (random set of extensions on shared hosting, some management panel to enable/disable on dedicated hosting), but what version (features/bugfixes) these extensions are will most likely be improved in the dedicated hosting scenario as you'd be able to pick "new features" vs "old and stable, bugfixes".

In the case you actually have control, you'll be able to "pecl/apt-get/yum install/upgrade" based on your preferences - latest features, or bugfixes only.

When will this be available?

There seems to be a great momentum on internals@ these days for making a lot of internal changes which will require a new major version of PHP. This is a perfect time to introduce a new PHP extension manager into the mix. Let PEAR and 5.x stay as-is, while the next major release of PHP that will dominate the next decade or so get an improved tool to deal with this.
The focus needs to be for the future, and once we have something solid.. We could think about adding support for the current extension system, although that should be a secondary goal - we need something for tomorrow, not yesterday.

-Hannes

[1] New functionality or security update
[2] Backwards compatibility breaking releases
[3] No centralized management
[4] No need to wait for PHP releases, or work overtime to make it in time for release
[5] No PHP version restrictions