On 2010-03-18, Lukas Kahwe Smith <m...@pooteeweet.org> wrote: > > On 18.03.2010, at 06:55, Andi Gutmans wrote: > >>> -----Original Message----- >>> From: Olivier Hill [mailto:olivier.h...@gmail.com] >>> Sent: Saturday, March 13, 2010 10:15 AM >>> To: Derick Rethans >>> Cc: PHP Developers Mailing List >>> Subject: Re: [PHP-DEV] PHP 6 >>> >>> We need to focus on Unicode more than what some says, whether this >>> means descoping the Unicode release or not. However, this means that >> the >>> development focus needs to be towards new features AND Unicode, not >>> having the new feature branch, and the siberia branch with Unicode >> support. >> >> I think the key to rebuilding momentum in PHP development is to not try >> and boil the ocean but to focus on "smaller" major releases. This would >> enable us to manage a more predictable release cycle, lower the risk for >> each release incl. better manage compatibility and increase motivation >> for contributors as they know they can have an impact and if they can't >> make one release they know the next isn't that far off (the latter also >> eliminates pressure to push pre-mature functionality into a release). > > Yeah, I wouldnt mind if we would aim for regular releases in late spring > early summer every year. This ensures that developers scratching their own > itch have a clear timeline by when their hard work can make it into a stable > release.
yes I agree with that. >> In that spirit I would not necessarily couple Unicode support and the >> next "smaller" major version. First I would suggest to build a >> well-defined, reasonably scoped list of functionality for the next drop. >> I think we should make only a few features must-haves and the rest >> should-haves so that only high-priority pieces of functionality can >> potentially hold up a release. It also helps with quality as high risk >> functionality that feels unstable could be pushed out if needed. This >> encourages pushing out functionality to our users sooner rather than >> later (in the realm of reason). > > +1 +1 > >> Then as far as Unicode support is concerned I think we need to work in >> parallel on various RFCs that can provide alternative ways of >> approaching the Unicode problem. Given the performance hit, memory >> overhead and complexity of the current implementation (which I also >> supported) I think we should try and look for a solution that is more >> pragmatic and is more explicit - giving the average PHP user the same >> experience, compatibility and performance characteristics of PHP 5.x >> while giving the more sophisticated users who need Unicode the tools to >> build global applications. > > > +1 .. this all aligns perfectly with my suggestion to establish a "unicode > working group" that I made in the "PHP 5.4 branch and trunk" thread. so just > like you i agree that we shouldnt put the next release under the pressure of > delivering "the unicode answer" .. if the working group gets done in time we > can move it into the release plan, if not .. so it goes .. with regular > releases the next chance to get unicode in isnt too far off. I agree. For sure we should keep the unicode group open and transparent, but as andi and lukas said, we shouldn't force unicode to be inside the next version. So people that want to work on unicode should get together and prepare RFCs. Probably Derick and others like to help with that as already pointed out. But the next release should be pragmatic and not depend on things taht are very uncertain at the moment. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
