It seems that most people still don't really get the idea behind
PECL, and how moving extensions there is a good idea.
Let me spell it out for you:
- PECL provides a way to keep your extensions self contained and
allows you to keep your own release cycle.
- In addition, the packaging systems allows you to mark the package
with explicit, versioned, dependencies.
- It is very easy to our users to install and upgrade these
"pickled" extensions.
---> PECL is a great solution for self-contained extensions
How does it help with the core?
- As we move extensions from php-src/ext to pecl/, they can take
advantage of the PECL infrastructure.
This allows people to build their own PHP and pick and choose the
particular version(s) of extensions that they want to use.
They might not want to use the very latest stable version if they
have a policy for avoiding bugs; conversely, they might want to
be using the latest version of the extension because it fixes
some bugs.
What is the resistance to moving stuff from the core?
- PECL is still seen as Siberia. Some developers "fear" that
putting extensions in PECL will result in them having lower
quality because PECL extensions are somehow harder to test.
This is a totally bogus argument. Getting extensions from
PECL is just as hard or easy as getting anything else from CVS,
it is just an additional module to check out. There is nothing
hard about that, unless you are lazy.
The new win32 build system doesn't give a damn about whether
your extension is in PECL or in the core; it will still compile
it and run any tests in the test suite; the unix build should
be able to do this too (currently it is a little painful for
regular, non-golden extensions, but that shouldn't be hard to fix).
- Some developers simply cannot see that there are two "problems"
with having our "golden" extensions in PECL:
- Development
- Packaging
They see them as a combined issue, and get confused about how
to handle things.
Using appropriate means on the CVS server, we can make the golden
pecl extensions appear under ext/ at the time you check out the
sources. Those sources will be HEAD, or whatever other branch
you requested. Development continues as it always has done in
the past.
At Packaging time, when the Release Master (lets call him
Peter Piper) rolls the tarball, he will pick the latest stable
versions of those golden pecl extensions.
Typically, these will be the same versions as can be found on
the current branch, as golden extensions are kept in sync with
the core; but he may decide to use an older stable version of
the package if he decides the latest version isn't up to scratch.
The "pear bundle" tool makes it simple for Peter Piper to
"pick a pecl".
This approach gives us more flexibility with our releases, without
overly complicating the common case.
Furthermore, it allows the end user to build their extensions
as shared modules and then upgrade them to a more recent version
in between major releases of the core.
I'm tired of hearing FUD about PECL; lets stop resisting it and
start embracing it.
--Wez.
"King" of PECL
(whatever that means)
