> 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
