On 13.03.2010, at 17:57, Derick Rethans wrote: > I do however think that most of the current approaches of adding Unicode > support into PHP 6 (current trunk) have the proper ideas behind that, > but I do think that in some cases we went slightly overboard of > supporting Unicode everywhere with the new "unicode" type. For example, > we don't really need to have this for variable or function names or > support every encoding for writing scripts in. (We do > need to *support* Unicode there, but not with the unicode string type.) > Another example is that we perhaps don't have to support every encoding > out there.
Right, dropping the current trunk doesnt mean that we should forget about unicode. However we need to find a balance between ease of use, performance (especially for those who do not need better unicode support) and release timeframe. > So I would suggest the following things to do: > > - get rid of Jani's play branch > - move trunk to branches/FIRST_UNICODE_IDEA > - put 5.2 in security fix only mode > - pht 5.3 in bug fix only mode > - start adding new features (traits, Ilia's scalar typehint patch, > output buffering things) to the new trunk cloned from 5.3. +1 As for the exact features to merge, lets first start with formulating a plan about what we want to see in the next release. I also think it makes sense to base the number and scope if the features on a rough idea of when we want to see this next release. In order to put together that release plan i guess we should have an RM defined first. I think Andi said the same thing on IRC yesterday. I can certainly see you as RM, but i would like to propose another newer guy for the job: David Soria Parra That being said, I also think that the model of a co-RM that focuses on the less technical aspects as proven itself with 5.3. not only does it mean the work load is spread over two shoulders, it also means that developers can get answers quicker (especially as we are all sometimes swamped with work or god forbid go on vacation). I am willing to take the co-RM role again. I can also see Philip in this role. But I think the more important question is to find the technical RM and if the technical RM feels like he can use the support he can just appoint a co-RM. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
