Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:2215
Return-Path: <frank@kromann.info>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 9629 invoked from network); 8 Jun 2003 05:10:41 -0000
Received: from unknown (HELO mail.kromann.info) (64.186.239.125)
  by pb1.pair.com with SMTP; 8 Jun 2003 05:10:41 -0000
Received: from Swwwing2000 (unknown [64.186.239.115])
	by mail.kromann.info (Postfix) with SMTP
	id 8A7CB2AE25; Sat,  7 Jun 2003 22:10:44 -0700 (PDT)
To: Edin Kadribasic <edink@proventum.net>
Cc: internals@lists.php.net,
	Sterling Hughes <sterling@bumblebury.com>
X-Mailer: Swwwing 2000
Message-ID: <10550490805600000@9866357972520000.9866341568840000>
MIME-Version: 1.0
Reply-To: "Frank M. Kromann" <frank@kromann.info>
Date: Sat, 07 Jun 2003 22:11:20 -0700
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Moving to PECL
From: frank@kromann.info ("Frank M. Kromann")

I agree with Edin here. We need to make sure the Windows builds are not too
far behind the *nix releases. In other words we need to make sure
everyting is in place to build and release on Win32 before we move all
extensions.

- Frank

> On 7 Jun 2003, Sterling Hughes wrote:
> 
> > Hi,
> > 
> > So now that the PEAR framework for bundling extensions is in place, I
> > figured I'd start a thread about moving all extensions to PECL, and
then
> > selectively bundling them from PECL (perhaps maintaining physical
> > aliases as well.)
> 
> -1
> I'm strongly against this move. First of all PEAR framework for handling

> extensions is nowhere near complete. It has no support for Windows. It
has 
> no notion of what version of PECL package can be built with what version

> of PHP. It requires latest and the greatest GNU tools installed on the 
> system which is rarely true for some commercial Unixes.
> 
> If we are going to bundle most of those extensions anyway, removing them

> to PECL would directly reduce the quality of the release as most of them

> will receive very little testing.
> 
> I understand the wish to make the release process more easy, but I'm 
> afraid that this proposal will achieve exactly to opposite effect. It
will 
> certainly make maintenance of the Windows binary releases much more 
> difficult.
> 
> Edin
> 
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>