Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47343
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 188.40.37.16 cause and error)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <alpine.DEB.2.00.1003161545500.4153@kossu.derickrethans.nl>
Date: Tue, 16 Mar 2010 22:29:58 +0100
Cc: PHP Developers Mailing List <internals@lists.php.net>,
 Scott MacVicar <scottmac@php.net>,
 Ilia Alshanetsky <ilia@php.net>,
 =?iso-8859-1?Q?Johannes_Schl=FCter?= <johannes@php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <76412548-72DE-42D8-979D-9BD52AF754F8@pooteeweet.org>
References: <alpine.DEB.2.00.1003161545500.4153@kossu.derickrethans.nl>
To: Derick Rethans <derick@derickrethans.nl>
Subject: Re: [PHP-DEV] PHP 5.4 branch and trunk
From: mls@pooteeweet.org (Lukas Kahwe Smith)


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=20

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=20
> that for now, but I'd like to do the following soon:
>=20
> - Declare 5.2 security fixes only (Something for Ilia to declare).
> - Declare 5.3 bug fixes only (and ini-mini features if so desired)=20
>  (Something for Johannes to declare).

+1

> - the new output buffering mechanism (I can not really see why we =
would=20
>  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
mls@pooteeweet.org