Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:2832
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <079f01c33be9$5f55e7b0$06dea8c0@cyberware.local>
To: "Adam Dickmeiss" <adam@indexdata.dk>
Cc: <internals@lists.php.net>
References: <5.1.0.14.2.20030626131542.05a31fd8@localhost> <200306261107.h5QB77P29080@www.digarc.com> <5.1.0.14.2.20030626155109.059eb1e0@localhost> <20030626130951.GA2722@indexdata.com>
Date: Thu, 26 Jun 2003 09:46:40 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] xml and libxml versions
From: rrichards@ctindustries.net ("Rob Richards")

From: Adam Dickmeiss

> Bundling gives many problems. So if a Unix machine has libxml/libxslt
> installed (most do) and if that version is supported by PHP the configure
> should use that (and not a bundled version). If the PHP people
> only allows a very strict set of libxml versions that's a sign
> of a problem in ext/xml.* (not in libxml). libxml API doesn't change.

I am not suggesting that we restrict the versions of libxml that people can
use. The API calls may not change, but the logic within can and does.
Without being able to say that versions x,y,z are supported, what is
considered a PHP bug and what is considered a change from libxml (and how
can we tell).

We are going to be right back to bug reports where people say things are
broken when it is really that they are running newer/different versions of
libxml. Who decides which is right? Are all the extension maintainers
supposed to get togther agree to an upgrade and then start writing custom
xml code in order to support the older versions and not break BC? Do you
know how many times I have gone through different versions of libxml souce
code from bug reports when it ended up being changes within libxml.

It was a pain to deal with when there is a single extension using it, but
now there are currently 3 that depend on it, 1 that uses it but can use
expat, and another one on its way that will depend upon it. It could turn
into a nightmare.

All I am suggesting is that there is a version(s) - could be more than one -
that the extensions are based on and tested against. If people are running
something different and the behavior of the library has changed it is not a
bug in PHP, so they have the option to live with the changed behavior or run
with a supported version.

Rob