My take and a bit of a clarification for Andi. I wasn't criticizing you personally, I was criticizing the Release Manager which happens to be you. Admittedly the distinction is subtle. The RM's job is to heard cats. You take input from everyone and make a decision on when to freeze and when to release. After a freeze you fend off people who want to sneak in changes that are not obvious bug fixes. If someone convinces you that a bigger picture change is required, then you have a problem and I don't think just quickly squeezing that change in and pushing out a new release before too many people have downloaded the previous release is the right solution to that problem because we need time to figure out the ramifications of such a change. For example, how many PEAR packages might we break with this? Are any of them perhaps even in the php5 tarball itself?
On the Studlycaps issue my opinion is that it is a guideline and while it would be nice to have consistency in the end it is ultimately up to the extension authors to decide whether they wish to follow the guideline or not. I have no plans on going back and breaking the few extensions I have written that have OO APIs because I don't think aesthetic changes is worth breaking BC over, but I will probably follow the guideline for new ones. We could make the decision that we will not bundle any extension that doesn't follow the guidelines although in this case that might not be a good idea. I see 3 ways forward: 1. Stick with the freeze and deal with the inconsistency 2. Remove the freeze, convince Georg to make the change (if possible) and make very sure people realize that RC1->RC2 is not just bug fixes 3. Unbundle mysqli to pecl and let it evolve at its own pace and we can include it in the standard tarball when everyone is happy with it -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
