Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:47391 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 3436 invoked from network); 18 Mar 2010 09:12:21 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Mar 2010 09:12:21 -0000 Authentication-Results: pb1.pair.com header.from=mls@pooteeweet.org; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=mls@pooteeweet.org; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 188.40.37.16 cause and error) X-PHP-List-Original-Sender: mls@pooteeweet.org X-Host-Fingerprint: 188.40.37.16 hq1.backendmedia.com Linux 2.6 Received: from [188.40.37.16] ([188.40.37.16:33923] helo=hq1.backendmedia.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2F/62-20429-37EE1AB4 for ; Thu, 18 Mar 2010 04:12:20 -0500 Received: from localhost (unknown [127.0.0.1]) by hq1.backendmedia.com (Postfix) with ESMTP id C2AD72E3001B; Thu, 18 Mar 2010 09:12:15 +0000 (UTC) X-Virus-Scanned: amavisd-new at backendmedia.com Received: from hq1.backendmedia.com ([127.0.0.1]) by localhost (hq1.backendmedia.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmTlDfnyORBb; Thu, 18 Mar 2010 10:12:15 +0100 (CET) Received: from [192.168.0.151] (217-162-131-234.dclient.hispeed.ch [217.162.131.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mls@pooteeweet.org) by hq1.backendmedia.com (Postfix) with ESMTPSA id 0E0C12E30016; Thu, 18 Mar 2010 10:12:14 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii In-Reply-To: <698DE66518E7CA45812BD18E807866CE03ECF62E@us-ex1.zend.net> Date: Thu, 18 Mar 2010 10:12:14 +0100 Cc: "Olivier Hill" , "Derick Rethans" , "PHP Developers Mailing List" Content-Transfer-Encoding: quoted-printable Message-ID: References: <4B9926E8.4080202@lerdorf.com> <698DE66518E7CA45812BD18E807866CE03ECF62E@us-ex1.zend.net> To: Andi Gutmans X-Mailer: Apple Mail (2.1077) Subject: Re: [PHP-DEV] PHP 6 From: mls@pooteeweet.org (Lukas Kahwe Smith) On 18.03.2010, at 06:55, Andi Gutmans wrote: >> -----Original Message----- >> From: Olivier Hill [mailto:olivier.hill@gmail.com] >> Sent: Saturday, March 13, 2010 10:15 AM >> To: Derick Rethans >> Cc: PHP Developers Mailing List >> Subject: Re: [PHP-DEV] PHP 6 >>=20 >> 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. >=20 > 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. > 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 > 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. regards, Lukas Kahwe Smith mls@pooteeweet.org