Le 31/01/2014 22:30, Johannes Schlüter a écrit :
On Fri, 2014-01-31 at 20:18 +0100, gooh wrote:
This has the same issue as the 64bit RFC:
"This feature is proposed for inclusion in PHP 5.6"
For 5.6 we have an alpha out. We created a new release process after
learning that changes late in the game delay our releases and offer a
stronger guarantee that the following release is not in unforeseeable
future to make it a viable thing to delay changes by a release.
This is no evaluation of the feature itself.
johannes
Hi Johannes,
Out of curiosity I read both the Voting and Release Process RFCs and
couldn't find any mention of a rule stating that all votes had to be
approved before the first alpha, if I overlooked it, please correct
me. Also, If you look at the wikipedia definition of an alpha in, I
believe that it is still time to add features:
<quote>The alpha phase usually ends with a feature freeze, indicating
that no more features will be added to the software. At this time, the
software is said to be feature complete.</quote>
http://en.wikipedia.org/wiki/Software_release_life_cycle#Alpha
Also, isn't it to the Release Manager role to make such decisions?
I digged the archives from last month and I found this message from
Ferenc Kovacs and Julien Pauli who are RMs:
<quote>
Yep, that's to prepare for the future.
We *won't* merge any RFC after the first beta. Recall that everybody.
If you now have a new RFC, ok why not accept it in the 5.6 workflow
(even if we said no new RFC after first alpha) , let's not be too
strict, but be warned it *has to* be merged before first beta , that
is something like mid-march.
For sure, no new idea can be merged after first beta, so RFC will have
to be stabilized and voted and accepted for the mid-march dead-line.
</quote>
The document linked is:
https://wiki.php.net/todo/php56#timetable
The RFC was created before the first alpha, the voting phase is now
and if the result of the vote is a yes, then it has until mid-March to
be included. At least that's how I read it.
I am just a reader of the list, I unfortunately don't have the skills
to participate at this level of technicity, but maybe it would be good
for you guys to clarify the schedule and especially clarify the voting
process in this schedule since apparently you understand the 'No new
RFC' by alpha 1' as 'Only RFCs that got a positive vote before alpha 1
can be in the final realease'. I think it's probably the role of RMs
to clearly state what the wording they use means to make sure
everybody is on the same page.
My 2 cents,
Regards :)
Pascal
I think this should be included but I don't remember there being any discussion on this. Will this work with types?
public function __construct((foo) $this->x, (bar) $this->y);