How to handle integrating PECL extensions in our development and release
process is a somewhat tricky problem.  We first have to recognize two
basic characteristics of pecl extensions:

 A. Development/release schedule is independent of php-src schedule
 B. Some extensions will have specific changes for a particular php-src
    branch

For example, Wez had a PHP_4_3 branch in pecl/sqlite which was moved to
PHP_4 and confused him.

So, we need a way when we roll a php release to walk through a list of
extensions we plan on bundling with the release and grab the latest
release package that will work with our major release version.

So, perhaps something like this:

Say we are releasing PHP-4.4.8 and we have decided to bundle sqlite.
First we look to see if there is a stable sqlite release on the PHP_4_4
pecl branch.  If not, we look in PHP_4 and finally we fall back on
PHP_5/HEAD.  If it is a PHP5-only extension, then presumably it wouldn't
be on our list of extensions to bundle with PHP4 releases so it should be
safe to fall back to HEAD.

So CVS would look something like this:

http://lerdorf.com/cvs.png

So, likewise for PHP5 releases.  We for PHP-5.0.7 we would look in
PHP_5_0 then in PHP_5/HEAD for a release tagged extension.

Now, the other side of this is what we want to see when we check out a
source tree.  If I check out PHP_4_3, do I expect to see exactly what will
be in a PHP-4.3.x release including right branch of the pecl extensions
marked to be bundled with PHP-4.3.x?  Or do I only see the core PHP_4_3
and non pecl extensions?  Or, do I see core plus any pecl extensions that
have a PHP_4_3 branch?

The easy way out is to only worry about checking out core php-src code and
have the release tool go and figure out the extensions that need to be
bundled.  My worry with this is that we will have fewer eyeballs on the
complete release tarball.

I think the ideal would be some sort of cvs trickery which would allow us
to say:

   co -r PHP_4_3 php-src-pecl-release

which would give us the exact stuff that would be in the release so
everyone could work with it on a day to day basis.  But I am not sure how
to do this such that the branch fallback mechanism is followed.  It may be
too messy.  Perhaps every bundled extension has to have a branch that
matches the major release branch it is to be bundled with.  But,
non-bundled extensions need to be able to be on these major branches as
well without getting bundled.  So I am not sure how to do this selective
checkout.

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to