Re: RE: Fixing PECL + Core

Sorry about the poor choice of words. "Official" === Got a version number and can be downloaded on pecl.php.net Take APC as an example: latest pecl version = 3.0.14, released on 2007/04/02 latest cvs version = files apc_shm.h and apc_rfc1867.c, 6 days ago pecl4win version = compiled on 2007-05-29 03:17:04 (for php 5.2 and 5.1) On 5/29/07, Richard Quadling <rquadling@googlemail.com> wrote:

Isn't PECL4WIN "official"? It's on the php.net domain. On 29/05/07, Gaetano Giunta <giunta.gaetano@gmail.com> wrote: As a side note: does anyone think that providing on pecl4win compiled versions corresponding to the official pecl package releases besides the "compiled from cvs" versions would be a good idea? Bye Gaetano On 5/29/07, Richard Quadling <rquadling@googlemail.com> wrote:

My post about SNAPS and PECLS a little while ago seems relevant to

this.

As a windows user, I have to rely on pre-compiled binaries. It was/is my understanding that SNAPS would provide me with most currently succesfully compiled PHP, with some extensions built in and some extensions for my ext directory - those which are deemed important enough (judge important as you would like). PECL contained other extensions - those NOT part of the windows "standard" package. On 27/05/07, Gaetano Giunta <giunta.gaetano@gmail.com> wrote:

Just to add my experience (even though the original poster

explicitly

asked for single extensions not to be mentioned) from a not-completely-unrelated problem: some extensions have an "internal" version number that is not always updated when the userland API of

said

extension is changed - see eg. Json and the recent change of

behavior on

decoding scalar values. This makes it very hard for people maintaining php libraries to code defensively and test the version in use to enable workarounds: - the extension version number is useless (if not managed correctly) - the php version number is useless, since the extension might have

been

downloaded and compiled from pecl and not correspond to the version

that

is distributed with the core The only option left in this situation is to test the functionality needed first, then use it, much as it is done in js - a very sad

state

of things... (of course I would not recommend disabling upgrade / backport of a php extension from pecl as a solution) The fact that the extension lives in both pecl and core and the two might be slightly out of sync does not help at all when trying to

find

out the cause of regressions... Bye Gaetano -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

-- ----- Richard Quadling Zend Certified Engineer :

http://zend.com/zce.php?c=ZEND002498&r=213474731

"Standing on the shoulders of some very clever giants!"

-- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!"