PHP 5 RC1

On Tue, Nov 11, 2003 at 10:01:32PM +0100, Stig S. Bakken wrote:

i think andi hopes that only RCs will give us the needed momentum to get it finished (as in we labelit RC but it's a beta). i have real opinion on that, but if it helps PHP 5 i'm all for it. tc PS: same as andi, one of the few mails in the last weeks;-)

At 10:08 PM 11/11/2003 +0100, Thies C. Arntzen wrote:

To be honest, I think the answer is somewhere in the middle. Basically, the engine is done. I think the XML extensions and SQLite are pretty mature, and the old stuff pretty much works. Some people are already using PHP 5 in semi-production and I think it's quite stable. I'd really like to see PHP 5 get out soon because it's really a waste that we don't give PHP users the chance to use the new functionality. I think the emails I have been getting about tiny features people still want in all sorts of extensions is not a reason to delay PHP 5, for three reasons: a) There are always people who want another few things. b) Many of those people aren't doing anything useful to getting those things done. c) We all know that PHP always had a TODO, whether it was before PHP 4.0.0, before 4.0.2, or 4.3.4. I also don't think we should be waiting for new extensions like PDO. It is impossible to synchronize with every extension out there. PDO sounds like it'll be something really useful, and when it's ready and useful enough it'll probably be part of PHP whether that is 5.0.0. or 5.6.4. If it's ready in time, then great. If not, it might be in 5.0.1 which is likely to follow 1-2 months after 5.0.0. What I suggest is the following. An immediate feature freeze and try and get the RC out of the door. If it takes 2 months and not 2 weeks that's fine with me, but I'd like it to converge. I'd like people who have outstanding issues/bugs they need to fix, to go ahead and fix them. Same goes for critical engine problems (aka me). But it's obvious, that all bugs will never be solved, because that has never been the case. Going back to Stig's answer, yes, I think the tree is in pretty good shape. Andi

Yes, but it's not only the engine that would be going into RC, it's the entire distribution. John has a very good point in that some of the changes that people are looking to PHP 5 for will be extension specific, releasing an RC before the extensions are more or less stable doesn't make sense to me. I perfectly understand the momentum issue, but IMHO the full product that's being shipped is not up to RC yet. Overly long RC cycles are just painful. What about rolling b3, await some feedback, and based on that make a decision on rolling the first RC? - Stig On Tue, 2003-11-11 at 22:26, Andi Gutmans wrote:

At 07:37 12/11/2003, Stig S. Bakken wrote:

I think that this is one of the cases where the saying 'The biggest enemy of good is perfect' applies. I pretty much disagree with the main point of John. The key features of PHP 5.0, the ones people are talking about, are the new object model, XML (SimpleXML), and maybe mysqli and SQLite. These are all in very good conditions, all RC-quality AFAIK. Waiting for additional features is wasting time, as simple as that. It doesn't come to say that these additional features are not important. They may very well be very important. But the fact we've been sitting on so many features, ZE2, SimpleXML, mysqli and more and not giving the general public access to them makes no sense. I just can't agree with the notion of 'It makes no sense to release 5.0, just to release 5.1 shortly afterwards'. To that I say - it sure does! That's typically the opensource approach, release early, release often. Given our release cycles as of late, there's no chance we'll meet that theme even if we release tomorrow morning :) But we shouldn't go to the opposite extreme. My suggestion - we'll work on fixing ZE2 bugs (*). Fix as many as we can as soon as possible, and aim to release on Dec 15. Worst case - we'll delay to Xmas. If enough changes accumulate - we can have B3 too, but I'm not sure it will be necessary, because the betas don't appear to gain too much interest, at least not the kind of interest we need from the wide public. At this timeframe - if somebody feels he has some very pressing matter that, for some reason, must be ready for PHP 5.0.0 - by all means, finalize it. You have more than a month. But even more importantly, be advised that it's almost certain that this feature does NOT have to be in PHP 5.0.0. It can be in 5.0.1, or 5.1, or 5.2. Guys, major PHP 4 features (like output buffering, output compression, XML support) came post PHP 4.0.0. Now, while popping mail over a 24,000bps modem in some hotel in Tokyo, I just saw that Andi suggested that we go for Beta 3 around Nov 30. To be honest - again, given the relative lack of wide feedback for the betas - I don't think it will be very beneficial, but I don't think it'll do any harm either. I think we should still try and aim for RC1 for Dec 15, unless we get major negative feedback for B2 or B3 by that time. BTW - I agree with Edin about some issues that need to be solved, with the most important one IMHO being libxml bundling. In all efforts to avoid a thread on this subject of any shape or form - I'd really like to push the approach of having two source dists - one w/ libxml, and one w/o it, both created by makedist, and available for download. I think that even the biggest advocates of bundling as well as the biggest advocates of PHP-purity can live with that solution. Now the only question is whether there are any volunteers to make the necessary patches to PHP's build as well as makedist that will make this magic ;) Zeev (*) I think many of those are actually old ZE1 bugs that were tested to also break ZE2, and given the fact I told Jani that ZE1 bugs are second priority, he retagged them as ZE2 bugs. You may have to keep them for downwards compatibility ;)

*This message was transferred with a trial version of CommuniGate(tm) Pro*

nice idea, but you and i both know how lazy people get, when they have to write docs or articles instead of producing awesome code ;). I really would like to see Zend doing such a campaign, not because i think you are responsible to do so, but because it should be/is worth the money for your company (roi).

sorry. i believe you have personal ambition in this - ofcourse. But nevertheless i think that the release is important for Zend as a commercial company (looking at those deals with sun i.e.) ;) cheers -Wolfgang

Edin Kadribasic wrote:

I've submitted different .dsp/.dsw files to fix this problem, and I even posted a diff file to do the same job. No one responded and no one commited it. Oliver

From: Edin Kadribasic

Took a stab at the libxml2 stuff and ran into a few issues. The biggest issue was iconv. Was hung up on trying to get libxml to link statically to iconv and then re-export its symbols, which could then be re-exported in php4dllts. I got so far to build a custom libxml, as it normally links dynamically to iconv as well as a custom libxslt as we would need a static lib for this which would dynamically link to the libxml symbols exported by php4dllts. All but the iconv linking worked, though to export the libxml2 symbols we would need a def file or include all its headers, otherwise only a subset get exported which a few functions were missing needed by the xsl extension. Edin, could you also update the libxslt you are currently building against? The one you are using is linked against libxml 2.5.4, while the libxml you are using is 2.5.10, which is causing a few minor issues. You can grab the libxslt release built against 2.5.10 at http://www.zlatkovic.com/pub/libxml/oldreleases/libxslt-1.0.32.win32.zip Thanks, Rob

I've been using static builds of iconv and libxml2 for quite some time. Do you need the .dsp's? Zeev At 14:38 19/11/2003, Rob Richards wrote: