Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42635
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 83.243.58.133 cause and error)
To: Stanislav Malyshev <stas@zend.com>
Cc: 'PHP Internals' <internals@lists.php.net>
In-Reply-To: <496E65B2.1070106@zend.com>
References: <496E65B2.1070106@zend.com>
Content-Type: text/plain
Date: Thu, 15 Jan 2009 11:49:14 +0100
Message-ID: <1232016554.12981.56.camel@goldfinger>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] build IDs proposal
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Wed, 2009-01-14 at 14:22 -0800, Stanislav Malyshev wrote:
> I think that it would be better if we adopted more clean and scalable 
> solution for that. I propose having one string build ID, which would 
> look something like: "API20071006,NTS,Debug,VC8" and would be rquired to 
> match exactly in the engine and the module. This should be relatively 
> easy to generate when compiling.

In general: Yes, making this extendable is good.

But a few comments:

- We should make sure not to over-specify things, some minor things can
be irrelevant for 99% of the cases (like the old memory limit: for all
extensions, except XDebug, this didn't matter but including it in the
version string creates trouble and XDebug would either miss a feature
(memory profiling) or not load due to a "symbol not found" ...)

- We (usually) guarantee binary compatibility for bug fix releases (z in
x.y.z) maybe we could use x.y in the version ID - mapping from API No.
to version No. is a pain

- While at it: Do we really need _three_ version IDs? (Zend API, PHP API
and ZendExtension API...)

- Loading a 5.2 ext in 5.3 or vice versa should give a nice error, too
(... as long as there's no "symbol no found" at least)

johannes