On Sat, 14 Jun 2003 19:24:03 +0200
"Tomas V.V.Cox" <[EMAIL PROTECTED]> wrote:
>
> That's we call dependencies, and the pear cmd supports a wide range of
> them, including: package, extension, php, zend, os, external prog,
> etc. Can you solve all this with CVS branches/tags? ;)
As a sidenote, yo
- Original Message -
From: "Edin Kadribasic" <[EMAIL PROTECTED]>
> > There is already support for: 'alpha','beta','stable','snapsho
> > t','devel' package states, plus all the version number formats supported
> by
> > version_compare(). IMHO that's more than enough.
>
> Its not. There is
> There is already support for: 'alpha','beta','stable','snapsho
> t','devel' package states, plus all the version number formats supported
by
> version_compare(). IMHO that's more than enough.
Its not. There is now way to tell which PECL extension version works with
which PHP version which is ess
"Georg Richter" <[EMAIL PROTECTED]> escribió en el mensaje
news:[EMAIL PROTECTED]
> On Sunday 08 June 2003 18:23, Rasmus Lerdorf wrote:
> > The one point on the QA issue is that nobody ever looks through all the
> > PECL extensions, but we occasionally grep through all the ext/*
extensions
> > to
On Sunday 08 June 2003 18:23, Rasmus Lerdorf wrote:
> The one point on the QA issue is that nobody ever looks through all the
> PECL extensions, but we occasionally grep through all the ext/* extensions
> to make sure that an API change, or just a simple mistake that we found
> does not occur in ot
Hi,
this is a general reply to what seems to be a theme in this thread. Here
are my observations and comments.
It seems to me that a lot of comment from php-dev people is mostly
concerned about getting control over PECL. I generally agree that
php-dev people have more to do with maintaining the c
"Rasmus Lerdorf" <[EMAIL PROTECTED]>
> I know the reasoning, but you were discounting everything except the
> versioning which I simply pointed out could be done without the move just
> as effectively. PECL's versioning support is no better than what can be
> done directly with CVS.
There is al
On Tue, 10 Jun 2003 15:37:31 +0200
Martin Jansen <[EMAIL PROTECTED]> wrote:
> Splitting PECL out of PEAR in terms of the website (*) will improve
> PECL's position a lot: Right now people consider it to be a subset of
> PEAR (the PECL packages are really pretty much hidden in PEAR atm) and
> thus
On Tue Jun 10, 2003 at 11:4042AM +0200, Pierre-Alain Joye wrote:
> On 10 Jun 2003 11:36:09 +0200
> Per Lundberg <[EMAIL PROTECTED]> wrote:
>
> > On Sun, 2003-06-08 at 18:23, Rasmus Lerdorf wrote:
> > > Getting it out of PEAR and up to its own top-level cvs module is a
> > > start.
> >
> > +1 on t
On 10 Jun 2003 11:36:09 +0200
Per Lundberg <[EMAIL PROTECTED]> wrote:
> On Sun, 2003-06-08 at 18:23, Rasmus Lerdorf wrote:
> > Getting it out of PEAR and up to its own top-level cvs module is a
> > start.
>
> +1 on this -- I know myself, when I was trying to find a PECL module
> that I *knew* sho
On Sun, 2003-06-08 at 18:23, Rasmus Lerdorf wrote:
> Getting it out of PEAR and up to its own top-level cvs module is a start.
+1 on this -- I know myself, when I was trying to find a PECL module
that I *knew* should be somewhere, but I had no idea that it would be
hidden in the PEAR module...
--
On Sun, 8 Jun 2003, Rasmus Lerdorf wrote:
> On Sun, 8 Jun 2003, Sterling Hughes wrote:
> > I agree 100%.
> >
> > Also, do note that all common extensions will still be direct aliases.
> > Meaning there should be no difference from a development perspective
> > (we'll still have the same set of ext
On 8 Jun 2003, Sterling Hughes wrote:
>Err. The release manager does:
>
>php5]$ ./bundle-release
>
>Which bundles the stable version of all the extensions we decide belong
>in php5. Whether this list grows our shrinks would require group
>concensus, and is not the issue here.
So none of tho
Sterling Hughes wrote:
MR> (Sorry if I missed something, but this seems like a no-brainer)
Forcing all developers to work with a broken environment will make
development ineffective/inefficient.
The distribution is "broken," but that doesn't affect development. The
only difference from a develo
On 08 Jun 2003 12:31:11 -0400
Sterling Hughes <[EMAIL PROTECTED]> wrote:
> I agree 100%.
>
> Also, do note that all common extensions will still be direct aliases.
> Meaning there should be no difference from a development perspective
> (we'll still have the same set of extensions in cvs, for a
It's not like PHP5 will get out the door any time soon. If the plan is
to move all php5 extensions to PECL, why wait? Move them. Fix things.
Seems like a good idea, and fairly straight forward, especially when
you have someone as capable as Sterling volunteering to do the work.
Best Regards
Mike R
On Sun, 8 Jun 2003, Rasmus Lerdorf wrote:
[snip]
> Basically my point is that instead of pushing extensions into the current
> void that is PECL, we need to pull PECL from the void and make it work
> first. You seem to want to take the reverse approach. Push everything
> into PECL and by doing t
> Basically my point is that instead of pushing extensions into the current
> void that is PECL, we need to pull PECL from the void and make it work
> first. You seem to want to take the reverse approach. Push everything
> into PECL and by doing that force someone to fix it, versus fixing PECL
>
I know the reasoning, but you were discounting everything except the
versioning which I simply pointed out could be done without the move just
as effectively. PECL's versioning support is no better than what can be
done directly with CVS. The pear installer still doesn't work on Windows.
We obvio
On Sun, 2003-06-08 at 12:56, Rasmus Lerdorf wrote:
> On Sun, 8 Jun 2003, Sterling Hughes wrote:
> > I agree 100%.
> >
> > Also, do note that all common extensions will still be direct aliases.
> > Meaning there should be no difference from a development perspective
> > (we'll still have the same se
Rasmus Lerdorf wrote:
> we just need developers to tag their extensions when they deem them
> stable and makedist simply checks out the latest stable version of
> the extension. Problem solved.
Sounds like a good plan to me as it should solve the problem without
causing trouble.
--
Sebasti
On 8 Jun 2003, Sterling Hughes wrote:
> php5]$ ./bundle-release
>
> Which bundles the stable version of all the extensions we decide belong
> in php5. Whether this list grows our shrinks would require group
> concensus, and is not the issue here.
>
> Would you prefer bundling code that is a wor
On Sun, 8 Jun 2003, Sterling Hughes wrote:
> I agree 100%.
>
> Also, do note that all common extensions will still be direct aliases.
> Meaning there should be no difference from a development perspective
> (we'll still have the same set of extensions in cvs, for all practical
> purposes). The onl
On Sun, 2003-06-08 at 12:38, Edin Kadribasic wrote:
> On 8 Jun 2003, Sterling Hughes wrote:
>
> > What does PEAR's stability on windows 32 systems have anything to do
> > with it? This is an internal change. Meaning, as an end-user, you
> > won't see any change. The separation to PECL is purely
On 8 Jun 2003, Sterling Hughes wrote:
> What does PEAR's stability on windows 32 systems have anything to do
> with it? This is an internal change. Meaning, as an end-user, you
> won't see any change. The separation to PECL is purely a release
> management thing.
>
> The move to PECL has been
I agree 100%.
Also, do note that all common extensions will still be direct aliases.
Meaning there should be no difference from a development perspective
(we'll still have the same set of extensions in cvs, for all practical
purposes). The only difference is that when the release manager goes
ah
On Sun, 8 Jun 2003 09:23:29 -0700 (PDT)
Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
> The one point on the QA issue is that nobody ever looks through all
> the PECL extensions, but we occasionally grep through all the ext/*
> extensions to make sure that an API change, or just a simple mistake
> tha
The one point on the QA issue is that nobody ever looks through all the
PECL extensions, but we occasionally grep through all the ext/* extensions
to make sure that an API change, or just a simple mistake that we found
does not occur in other extensions.
We need to raise the priority of PECL/* in
What does PEAR's stability on windows 32 systems have anything to do
with it? This is an internal change. Meaning, as an end-user, you
won't see any change. The separation to PECL is purely a release
management thing.
The move to PECL has been agreed upon multiple times. We can't have the
rele
Hi,
Shane Caraveo <[EMAIL PROTECTED]> wrote:
> Marcus Börger wrote:
> >
> >
> > Some extensions like mbstring behave different when not builtin. So
> > i suggest we find out which theses are and let them in.
>
> Having them in pecl in no way prevents them from being compiled builtin.
I basical
> From: Alan Knowles [mailto:[EMAIL PROTECTED]
> Sent: Sunday, June 08, 2003 4:53 AM
> Is PECL going to move to the top level in CVS? - it's a bit hidden
away
> at the moment... (and I guess after these are moved - creating a
'real'
> php5 directory?? - so their's not so many empty directories l
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 n
Is PECL going to move to the top level in CVS? - it's a bit hidden away
at the moment... (and I guess after these are moved - creating a 'real'
php5 directory?? - so their's not so many empty directories lying around?)
Regards
Alan
Sterling Hughes wrote:
Hi,
So now that the PEAR framework for
I have been hearing about a move to PECL.
What is the difference between an extension compiled into libphp4.so
versus and extension in PECL?
Can someone fill me in.
md
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
Marcus Börger wrote:
Some extensions like mbstring behave different when not builtin. So
i suggest we find out which theses are and let them in.
Having them in pecl in no way prevents them from being compiled builtin.
Also for extensions like ext/gd i don't see any reason to move them
out of the
Hello Sterling,
Saturday, June 7, 2003, 7:15:23 PM, you wrote:
SH> Hi,
SH> So now that the PEAR framework for bundling extensions is in place, I
SH> figured I'd start a thread about moving all extensions to PECL, and then
SH> selectively bundling them from PECL (perhaps maintaining physical
SH>
James Cox wrote:
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.)
I'm +1 on this.. And already offered to move stuf
>
> 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.)
>
I'm +1 on this.. And already offered to move stuff, s
39 matches
Mail list logo
