This change also broke my extension. I'd like to have the extension
be buildable with all of 4.x without user intervention, so I'm trying
to figure out some way to handle the change via the pre-processor.
I thought that ZEND_VERSION, defined in zend.h, might do the trick.
Unfortunately, it is defined as a string, thus the C preprocessor
won't perform any comparisons against it. Perhaps in 4.0.6+ there
could also be a ZEND_VERSION_DOUBLE, eg:
#define ZEND_VERSION_DOUBLE 4.06
Does anyone have any clever solutions to this problem that I could use
> It's in everyone's interest to keep the API intact. The Zend API is now
> fairly stable (I don't expect compatibility breaking changes in the 4.0
> line); Judging from the experience of PHP 3.0, there too, the API
> stabilized around x.0.5.
> At 18:29 4/5/2001, Brian Foddy wrote:
> >A small point I'd like to raise here.
> >I noticed 4.0.5 made a change to the arguments of
> >by adding a "dupe" argument to the define and underlying function.
> >This of course broke any external custom modules that are not
> >changed appropriately. In this case the change was very simple,
> >but it raises a good question...
> >Are there some guidelines independent external modules can follow
> >to remain more compatible between releases? I'm not questioning
> >the right or need for underlying Zend API changes, obviously
> >when such changes are made all functions inside the PHP collection
> >are change accordingly. But are there suggestions to minimize
> >these in the future and get better notified when they do occur?
Dan Libby <[EMAIL PROTECTED]>, author of xmlrpc-epi
check out xmlrpc-epi -- a C library for xmlrpc with a fast PHP
and learn about xmlrpc, enabling remote procedure calls over the net.
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]