On Wed, Nov 24, 2010 at 1:41 PM, André Rømcke <a...@ez.no> wrote:
> On Tue, Nov 23, 2010 at 3:53 PM, Derick Rethans <der...@php.net> wrote:
>
>> On Tue, 23 Nov 2010, Matthew Weier O'Phinney wrote:
>>
>> > On 2010-11-23, Derick Rethans <der...@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.php
>> )
>> >
>> > 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 like
> 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 the
> 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 could
> 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 anytime.
> 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 branch
> 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 and /
> or a strict release process.
>
>
> - ar
>
