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.
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
