Re: [SVN-MIGRATION] Problems with php-src, PECL-linked extensions, and tagging

Philip Olson wrote:
 >
 > There's also the old [idealistic] idea of having every extension live in
 > PECL. In this scenario the release manager would take the desired stable
 > extensions and package them at release time for the RC then test. This
 > idea has been discussed a few times but gets forgotten likely due to the
 > large challenges/changes it poses, or if the PHP project simply does not
 > want this then we can determine that too. Do we want this? What are the
 > pros and cons? I forget most but if this idea feels possible then
 > scouring the lists for past discussions will be done.
 >
 > There are a few points which favour an option like #3:
 > - It's rare to have PECL extensions in core that also do PECL releases.
 > Once upon a time a few did, but today it appears only oci8 does.
 > - These dead PECL extensions should not be installable.

That is true for new versions of PHP, but users of older PHP versions
may still want to do an install.  The version number checks in
package.xml should be revved to limit the applicable PHP version
range.

 > For example,
 > 'pecl install filter' should never work (although it does today). So
 > following this example, having the symlink here lies and pretends
 > pecl/filter is alive.
 >
 > In other words, today there really is no such thing as an extension that
 > is both in PECL and Core so this symlink serves no good purpose except
 > maybe to share CVS commit history but thankfully SVN makes moving much
 > easier. But maybe Chris has something to say about OCI8 and why
 > Core+PECL exists for it and works.

The only time I think of OCI8 as being in PECL is when I upload a new
PECL package via pecl.php.net.  The underlying code repository
structure isn't so important to users or to my release process.

I'm +1 on moving the symlinked extensions under the PHP umbrella.

 From a purely operational point of view, having OCI8 installable from
the PECL system allows users of older PHP versions to get OCI8 patches
without the destablization of upgrading to a new PHP release.  PECL
releases are useful when an extension changes rapidly or
fundamentally.  For example the recent OCI8 1.3 (which works with PHP
4.3.9 - 5.x) is shipped starting with PHP 5.3 but is in PECL if anyone
has PHP 5.2 in production.

I use PECL OCI8 to build RPMs for older PHP versions.  When pecl4win
was operational, Windows users were able to get the latest OCI8 for
various PHP versions.  I'd still create PECL builds for the foreseeable
future no matter where the source code was.

I recognize there are fundamental open questions about the intent and
direction of PECL.

Chris

-- 
Email: [email protected]
Twitter:  http://twitter.com/ghrd