So we delay it for a few months, what's the big deal there?
There are several features that we want to insert to PHP 5 but are not because of the feature freeze (realpath cache, TSRM updates, etc.). There'll be plenty of reasons to go for 5.1 pretty much immediately after the release of 5.0.
Zeev
At 22:17 17/05/2004, Sara Golemon wrote:
> There is no such thing as a feature freeze in PHP land, historically. > And that minor bug has already been fixed. > Oh what wonderful news, that means I can start commit patches again! Let's see, I've got that source binding patch for the network stuff, I've got those compression filters that I thought were going to have to wait till 5.1 and be supported in 5.0 as a PECL package only so that's good. Oh and here's that nice little guy to support HTTP/1.1 chunked encoding, inline gzip deflates, and connection pooling... I guess if there's no feature freeze in PHP land then all this stuff can go in right now.
Either there is a feature freeze or there isn't. I appreciate the frustration of having to wait through long and tedious minor version bumps. I also appreciate the fact that historically PHP versioning has been sloppy, but that's not a justification for contuing bad behavior.
> Let me add to this: isn't this what "open source" is about? The bug did > not manifest itself on my system (FreeBSD). You pointed out the issue. I > fixed it. Cooperation prevailed. What's the big deal? > Let me respond by saying there wasn't a big deal. I asked if this was too late in the RC cycle to justify a non-critical exception to the feature freeze. The response of "Andi/Zeev okayed it" was fine. But now you're standing there telling me that there is no such thing as a feature freeze and THAT is a big deal. That promotes chaos and a bad end product. I don't give a rodent's hind quarters about the ini variable substitution patch, I care about putting out a good product. I care about knowing that there's nothing in the final release that hasn't been well tested. I care that I only saw that minor bug because it broke compilation in general, and god knows if it broke something less obvious. Has anyone tried this with the ever-problematic browsecap.ini file?
-Sara
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php