Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42626
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 88.198.8.16 cause and error)
Message-ID: <8F4C9909-17F8-4D22-ADFB-655E25A198E3@pooteeweet.org>
To: Stanislav Malyshev <stas@zend.com>,
 PHP internals <internals@lists.php.net>
In-Reply-To: <496E65B2.1070106@zend.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Thu, 15 Jan 2009 00:06:48 +0100
References: <496E65B2.1070106@zend.com>
Subject: Re: [PHP-DEV] [RFC] build IDs proposal
From: mls@pooteeweet.org (Lukas Kahwe Smith)


On 14.01.2009, at 23:22, Stanislav Malyshev wrote:

> Hi!
>
> As many of you know, one can build PHP engine in a number of ways  
> which are binary-incompatible - debug/no debug, thread-safe/not  
> thread safe, etc. Also, for windows we have now anther dimension -  
> we could build with VC6, VC8, VC9, etc. Loading modules built with  
> another, binary incompatible version, could lead to crashes and  
> malfunctions, thus Zend extension and PHP extension loaders check  
> these options, stored in special structure, to match module ones  
> with engine ones.
> Now the problem is that when we need to add dimensions, we will have  
> to change structures and maybe even edit some extensions, and as we  
> have more dimensions it becomes less manageable and more "hackish".
>
> 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.
> Pro:
> 1. Easy, robust and scalable way to match current and any future  
> build flavors
> 2. You can easily create "private" build flavors when testing binary- 
> incompatible changes
> 3. Build data is in readable form even inside binary, so binaries  
> could be automatically checked by Unix tools.
> Contra:
> 1. Well, it's change :)
>
> What do you think?

how much work will this be?
what kind of risk will it bring?
as in i guess its too late for beta1 .. i guess its not something that  
forces us to stay at alpha, but will that change alone require another  
beta before we go to RC?

regards,
Lukas