On 16.03.2010, at 16:58, Derick Rethans wrote: > I've just renamed the 5.4 branch to THE_5_4_THAT_ISNT_5_4 and moved
Eventually it should be deleted, if it helps at all in merging the OB change then it should be kept until that happens, otherwise it can be deleted now imho. The new 5.3 based trunk will emerge soon I am sure, but until then lets not bother with having to merge those changes. > trunk to the branch FIRST_UNICODE_IMPLEMENTATION. +1 > The next things to do is to re-create trunk from PHP 5.3; I've hold off > that for now, but I'd like to do the following soon: > > - Declare 5.2 security fixes only (Something for Ilia to declare). > - Declare 5.3 bug fixes only (and ini-mini features if so desired) > (Something for Johannes to declare). +1 > - the new output buffering mechanism (I can not really see why we would > not want this) +1 > - traits, there are also RFCs: > http://wiki.php.net/rfc/horizontalreuse > http://wiki.php.net/rfc/nonbreakabletraits +1 other stuff: http://wiki.php.net/todo/php60 http://wiki.php.net/todo/backlog That being said I think until we know if the next version will be a new major version, we should hold off on BC breaking cleanup stuff likes dropping register globals and friends. But we still might bundle APC with the next release for example, even if its not 6.0 .. -- As for unicode, I would like the next release to be planned independently of finding a solution for unicode, but with the clear option that it will be included if we find a good solution in time (like I said I think it would be good to shoot for a final release summer 2011, so beta phase in early 2011). I propose that sort of a unicode working group forms but much less formal than what I make it sound like. I think the discussions can remain on internals@ and hopefully alternative approaches will be documented as RFCs. But what I mean with working group is a list of a handful of names who feel responsible to keep this topic moving until a solution is found and who people know they can contact if they want to chat or whatever. Again if these guys find a workable solution that can be implemented this year and I am all for putting it into the next release. If not so be it, because I think the lesson learned in all of the PHP6/PHP5.3 release nightmare is that we should have regular releases. So I say we shoot for the release following the next one to come out in the summer of 2012. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
