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
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.
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 coreThe 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--
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
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
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.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 coreThe 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--
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
Isn't PECL4WIN "official"? It's on the php.net domain.
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
GaetanoMy 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.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 coreThe 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--
--
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!"
Isn't PECL4WIN "official"? It's on the php.net domain.
" the official pecl package releases", you missed the word "releases" :)
I do think that having DLLs based on the releases (like zip-1.8.10 for
example) would be a very good thing. I'm for one not a fan of using
snapshots on production servers.
I may use HEAD only for the releases but it defeats the main purposes
of HEAD in php-src (for the extensions being in php-src and pecl) or
in general: developments.
About Philip's original post, I will try to come up with a more
complete reply later this week.
--Pierre
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)
Isn't PECL4WIN "official"? It's on the php.net domain.
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
GaetanoMy 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.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 coreThe 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--
--
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!"
Yes, and the binaries are generated on the same box as the windows releases.
--Wez.
Isn't PECL4WIN "official"? It's on the php.net domain.
Hello,
getting back to the original point of Philips email. What is the
relation between PECL, especially for packages that make it into core?
Does making it into core mean that the PECL package is removed (unless
the developer in question is willing to continue maintance)?
Or is it maybe time that we start considering PHP releases more like a
Linux distro release (take the current kernel and add in a all relevant
stable package releases from PECL, QA the thing as a while for a while
and release)?
Partly this also plays into the entire question of do we care about
users running older minor versions of PHP (these are the people that
seem to benefit the most from PECL releases). Do we even want
independent releases of core extensions?
I also find the comments on updating the API versions very important. I
think this is something that is taken to lightly. Making sure that API
versions are updated is very important. Why is this not taken care of?
Do we lack a common standard for when to update the API version? Are
developers not aware of the importance? Do we need tools/infrastructure
to ensure that the API version is updated?
regards,
Lukas
PS: In context with the discussions about an infrastructure update, I
think the time is now to discuss how PECL<->core relate.
Gaetano Giunta 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?
Yes, the way it works at present does bother me. For this reason, in my
extension we develop in a branch, and merge into HEAD at each release.
It's a rather upside-down way of working, but it does the job.