Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » RE: Fixing PECL + Core »

RE: Fixing PECL + Core

php.internals

Gaetano Giunta

19 years ago
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

Richard Quadling

19 years ago
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!"

Gaetano Giunta

19 years ago
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:

Richard Quadling

19 years ago
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!"

Pierre Joye

19 years ago
On 5/29/07, Richard Quadling <rquadling@googlemail.com> wrote:
> 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

Gaetano Giunta

19 years ago
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:

Wez Furlong

19 years ago
Yes, and the binaries are generated on the same box as the windows releases. --Wez. On 5/29/07, Richard Quadling <rquadling@googlemail.com> wrote:

Lukas Kahwe Smith

19 years ago
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.

Caroline Maynard

19 years ago
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.