Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47387
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.185 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 17 Mar 2010 22:55:16 -0700
Message-ID: <698DE66518E7CA45812BD18E807866CE03ECF62E@us-ex1.zend.net>
In-Reply-To: <dc2522541003131015k7f38c733i21b128529b578d3f@mail.gmail.com>
Thread-Topic: [PHP-DEV] PHP 6
Thread-index: AcrC2VWgy+o5TBk8QS2A4AnQmi+OEwDg4GLQ
References: <4B9926E8.4080202@lerdorf.com> <alpine.DEB.2.00.1003131123540.4153@kossu.derickrethans.nl> <dc2522541003131015k7f38c733i21b128529b578d3f@mail.gmail.com>
To: "Olivier Hill" <olivier.hill@gmail.com>,
	"Derick Rethans" <derick@php.net>
Cc: "PHP Developers Mailing List" <internals@lists.php.net>
Subject: RE: [PHP-DEV] PHP 6
From: andi@zend.com ("Andi Gutmans")

> -----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.

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).

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).

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.

Btw, I do think we should feel comfortable to call the next major
version PHP 6 no matter what its content is (if it warrants a major
version). I think the PHP dev community should put a stake in the ground
and feel comfortable to redefine what PHP 6 is, whether it's with or
without Unicode. This isn't a Perl 6 situation. This group shipped PHP
5.3 which was a very big step-up and a quite impressive major version.

My 2 cents.
Andi