Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50470
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ez.no from 74.125.82.54 cause and error)
MIME-Version: 1.0
In-Reply-To: <AANLkTinbuQYMECw_46_mQQ8kCh95JoWXKP==OAatULTA@mail.gmail.com>
References: <AANLkTi=coWEEMNnr_SsTCo7HaXUPRwcJg7fUz=NjA8nq@mail.gmail.com>
 <alpine.DEB.2.00.1011230945310.24401@kossu.derickrethans.nl>
 <C4.22.28185.25ACBEC4@pb1.pair.com> <alpine.DEB.2.00.1011231448580.24401@kossu.derickrethans.nl>
 <AANLkTinbuQYMECw_46_mQQ8kCh95JoWXKP==OAatULTA@mail.gmail.com>
Date: Wed, 24 Nov 2010 13:43:32 +0100
Message-ID: <AANLkTikVdim6CYxJWaaCT9dr2V9Mrq5ZQ5mQG2O=yyQP@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: "Matthew Weier O'Phinney" <weierophinney@php.net>, 
	PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=0016368341d892c1bf0495cbd750
Subject: Re: [PHP-DEV] Hold off 5.4
From: ar@ez.no (=?UTF-8?B?QW5kcsOpIFLDuG1ja2U=?=)

--0016368341d892c1bf0495cbd750
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 24, 2010 at 1:41 PM, Andr=C3=A9 R=C3=B8mcke <ar@ez.no> wrote:

> On Tue, Nov 23, 2010 at 3:53 PM, Derick Rethans <derick@php.net> wrote:
>
>> On Tue, 23 Nov 2010, Matthew Weier O'Phinney wrote:
>>
>> > On 2010-11-23, Derick Rethans <derick@php.net> wrote:
>> > > On Mon, 22 Nov 2010, Felipe Pena wrote:
>> > > > . 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.ph=
p
>> )
>> >
>> > Sorry, but this is actually a pretty grave BC break.
>> >
>> > Currently, you can do the following:
>> >
>> > namespace Foo\Validator;
>> >
>> > class Int {}
>>
>> During our namespace discussion, this is exactly what I warned about. In
>> order to make use of namespaces, you need to have atleast two "elements"
>> in your class names otherwise we can still never introduce a new class.
>> But that was not listened too.
>>
>> > As Sebastian noted, it seems this should be addressed with the new
>> > lexer; I'd argue that if the current type hinting must introduce new
>> > keywords, it should wait until the new lexer is in place in order to
>> > insulate end-users from such changes.
>>
>> The new lexer however, is a slower; so not a viable solution right now.
>>
>> > With a defined release process, *everyone* knows what must be done, by
>> > when, making the process more transparent and *gasp* democratic.
>>
>> Well, I don't think we've ever been democratic. I probably think
>> that that wouldn't even work. Also, I think an alpha has pretty much
>> been announce nicely on time for people to know what's happening.
>
>
>
> I think what Matthew suggest here is something in the line of
> democratically defining a release process up front: features you would li=
ke
> to get in (a roadmap that clearly states that the content can change up
> until a feature freeze), a deadline for the feature freeze so that the
> process is predictable and appoint a release manager to be in charge of t=
he
> branch.
>
> Something like:
> - Branching next version from day one so you have one called next and one
> called trunk for edge stuff, and appoint a release manager to approve
> features as they are merged from development branch(es)
>  Alternatively (among several possible branch strategies) in DVCS you cou=
ld
> use topic branches for the edge implementations, this is cleaner (maybe),
> but the point is to have a release branch that can be stabilized at anyti=
me.
>  For a more in-depth branching possibility see:
> http://nvie.com/posts/a-successful-git-branching-model/
>
> - Define a feature freeze date, anything not ready feature or stability
> wise is moved to Next Next roadmap (they are not in the Next release bran=
ch
> anyway as it only has feature complete features at any point)
> And branch off Next Next and appoint a release manager for that branch so
> there is always an active release branch.
>

When feature freeze date for Next is reached.


>
> This will give a more predictable release schedule for everyone involved,
> especially for php users as it will give them a real hint on when the
> testing process of the next version will begin and some clue on when it
> might get finalized. All without having to introduce full fledge scrum an=
d /
> or a strict release process.
>
>
> - ar
>

--0016368341d892c1bf0495cbd750--