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 <[EMAIL PROTECTED]> wrote:
Isn't PECL4WIN "official"? It's on the php.net domain. On 29/05/07, Gaetano Giunta <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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!"
