Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50426
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender)
Date: Tue, 23 Nov 2010 09:57:38 +0000 (GMT)
To: Felipe Pena <felipensp@gmail.com>
cc: internals <internals@lists.php.net>
In-Reply-To: <AANLkTi=coWEEMNnr_SsTCo7HaXUPRwcJg7fUz=NjA8nq@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1011230945310.24401@kossu.derickrethans.nl>
References: <AANLkTi=coWEEMNnr_SsTCo7HaXUPRwcJg7fUz=NjA8nq@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [PHP-DEV] Hold off 5.4
From: derick@php.net (Derick Rethans)

On Mon, 22 Nov 2010, Felipe Pena wrote:

> Given the current state of trunk, I think 5.4 release process should
> not begin tomorrow (alpha or whatever other status). There are
> numerous identified issues that we need to fix before even think to
> begin with a release. For example:
> 
> - type hinting (or strict hinting)
> - no consensus
> - the RFCs are unclear
> - BC break introduced
> . classes named as any of the type hint scalar types
> do not work anymore
> aka class int {}

Yeah, there is a slight hint of a BC break in case you have a class 
named "int" or "float" etc. But there is:
http://uk.php.net/manual/en/userlandnaming.tips.php

Perhaps we can reduce the current list of classes:
int, integer, real, double, string, binary, scalar, array, object, 
bool, boolean
to what the manual uses though (for prototypes):
int, float, string, binary, scalar, array, object, bool
(Point #18 at http://doc.php.net/php/dochowto/chapter-conventions.php)

> - Traits may not be ready yet for pre-release
> - see http://svn.php.net/viewvc?view=revision&revision=298348
> - APC support

I don't see why this can't be done after post-branching/post-alpha1

> - There are many changes not BC with 5.x, as we allowed them for the
> development tree, before 5.4 was even a topic

What's the list?

> - APC is not yet bundled. Having the opcode bundle can raise issues by
> one or another, we should have it in from the very 1st release

Bundling it is a question of copying it over. It compiles, although I am 
not 100% whether it works. If it doesn't fit in the end in the timeline, 
we can always remove it again as it's a standalone extension.

> - pecl/http was planned to be bundled. What's the status?

I'm all for it; but again, it's just copying it over to trunk before we 
branch.

> We also have no plan about what will or will not be 5.4. This looks
> familiar, this is exactly how we begun 5.3 and it tooks literally
> years to be released. There is also actually no agreement to begin
> with 5.4 now.

Yes, but instead of defining "what is PHP 5.4", why not just go with 
what we have? Everything that's not in thre is for PHP-next-next again. 

> 5.4 should be hold off until we solved the listed issues and the
> release management RFC gets discussed and hopefully approved.

Why do you need a release management RFC? We've made releases for more 
than a decade just fine.

Stalling every time doesn't get us anywhere. IMO we should just go with 
it. Which means as a rough guide:

- copy over APC/pecl_http
- branch on thursday
- alpha next week
- build a list of things that needs doing in 5.4 to get it ready (with 
  possible options to get rid of apc/pecl_http if they are not up to 
  date enough)

I am absolutely against stalling again!

cheers,
Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug