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) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
