Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:6326
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: Jani Taskinen <sniper@iki.fi>
Cc: Wez Furlong <wez@thebrainroom.com>,
   PHP Internals <internals@lists.php.net>
In-Reply-To: <Pine.LNX.4.53.0312092220220.11768@ybpnyubfg.ybpnyqbznva>
References: <AE808FE6-2A7B-11D8-8016-000393C4A12A@thiesos.org>
	 <05e501c3be8e$bc5c39a0$8802a8c0@obsidian>
	 <Pine.LNX.4.53.0312092220220.11768@ybpnyubfg.ybpnyqbznva>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: Overture Services Norway
Message-ID: <1071040267.1478.14.camel@kirin.dev.trd.p4pnet.net>
Mime-Version: 1.0
Date: Wed, 10 Dec 2003 08:11:07 +0100
Subject: Re: [PHP-DEV] oci in pecl...
From: Stig.Bakken@overture.com ("Stig S. Bakken")

On Tue, 2003-12-09 at 21:21, Jani Taskinen wrote:
> On Tue, 9 Dec 2003, Wez Furlong wrote:
> 
> >> it was actually my idea to for the oci8 stuff - and have some new 
> >> maintainer maintain it in pecl.
> >
> >Yep, I remember.
> > 
> >> i see no valid reason against it. he can start hacking on it (in pecl) 
> >> starting today - once he is comfortable with it we'll nuke the ext/oci 
> >> and use(link, package) the stuff from pecl.
> >
> >We can go a little bit further than that; lets move it properly in
> >CVS and roll a pecl release (1.0), and then Tony can continue
> >his work in the way that pecl is supposed to be working.
> 
>     And you're moving us into the support nightmare..
>     Instead of asking what php version they use, we need
>     to start asking which possible versions of different
>     extensions they happen to use, how they compiled them,
>     etc. etc. etc.
>     
>     Thanks, but no thanks. Keep PECL as sibe...for the not-so-golden
>     exts and the rest in php-src.

We know which releases of which (pecl) extensions are bundled with each
PHP release.  But to meet this problem, we should ask people to attach a
dump of phpinfo() or phpinfo("extname") and make sure that contains the
necessary information.  At the very least, the extension version number
should be in there, preferably added automatically.  There's a field for
version number in the extension struct.  I recall you supporting me
whole-heartedly on the very same issue back in the 4.1.0 days when the
version info was added, remember?

How people compile the extensions should be clear from that also, at
least just as clear as it is today.

 - Stig