Hi,
After some discussion with David and Julien we come up with the following
timetable for the 5.6 release: https://wiki.php.net/todo/php56#timetable
So first alpha in January(we calculated with 4 alphas), first beta in
March(we calculated with 4 betas), first RC in May(we calculated with 2
RCs, but we will see), and we would like to have a final release in June.
As you probably all remember the first beta usually means feature freeze,
so no new additions are allowed, only fixes, so the code can stabilize in
the beta and RC phase.
Learning from the past we would also like to introduce a new rule about not
accepting new RFCs targeting 5.6.0 after the first alpha is shipped,
because given the discussion and voting period it can force us into a spot
where we have to chose between
- sticking with the original timetable, but introducing destabilizing
changes after the feature freeze - or having to delay/reject an already voted an accepted feature
- or to delay the first beta (and the feature freeze)
I hope we can agree that none of those options are desirable, so I would
like to ask you to hurry up with the new RFCs, if you want it to introduce
something interesting and/or useful addition to 5.6!
As you probably all remember the first beta usually means feature freeze,
so no new additions are allowed, only fixes, so the code can stabilize in
the beta and RC phase.
Learning from the past we would also like to introduce a new rule about not
accepting new RFCs targeting 5.6.0 after the first alpha is shipped,
because given the discussion and voting period it can force us into a spot
where we have to chose between
I like this: +1.
If it works well, then we probably want to announce the calendar a
little earlier for the 2015 release, since there's now a pretty narrow
window to propose an RFC and have it voted on before January 16. By my
estimation, an RFC will have to enter "in discussion" by December 26
(hope nobody has plans over the holidays) to be accepted for PHP 5.6,
assuming minimal two week discussion and one week voting periods.
Adam "Christmas Grinch" Harvey
PS: You'll all note how careful I was to avoid assigning a version
number to the 2015 release. :)
2013.12.12. 19:48, "Adam Harvey" aharvey@php.net ezt írta:
As you probably all remember the first beta usually means feature
freeze,
so no new additions are allowed, only fixes, so the code can stabilize
in
the beta and RC phase.
Learning from the past we would also like to introduce a new rule about
not
accepting new RFCs targeting 5.6.0 after the first alpha is shipped,
because given the discussion and voting period it can force us into a
spot
where we have to chose betweenI like this: +1.
If it works well, then we probably want to announce the calendar a
little earlier for the 2015 release, since there's now a pretty narrow
window to propose an RFC and have it voted on before January 16. By my
estimation, an RFC will have to enter "in discussion" by December 26
(hope nobody has plans over the holidays) to be accepted for PHP 5.6,
assuming minimal two week discussion and one week voting periods.
Nope, you can introduce RFCs until the first alpha, RFCs under discussion
or under voting are allowed to be added (until the first beta).
Ofc. this still leaves with only a month, which also includes chirstmas/new
year so not that much time, but we are already a bit behind schedule.
Adam "Christmas Grinch" Harvey
PS: You'll all note how careful I was to avoid assigning a version
number to the 2015 release. :)
2013.12.12. 19:48, "Adam Harvey" aharvey@php.net ezt írta:
As you probably all remember the first beta usually means feature
freeze,
so no new additions are allowed, only fixes, so the code can stabilize
in
the beta and RC phase.
Learning from the past we would also like to introduce a new rule about
not
accepting new RFCs targeting 5.6.0 after the first alpha is shipped,
because given the discussion and voting period it can force us into a
spot
where we have to chose betweenI like this: +1.
If it works well, then we probably want to announce the calendar a
little earlier for the 2015 release, since there's now a pretty narrow
window to propose an RFC and have it voted on before January 16. By my
estimation, an RFC will have to enter "in discussion" by December 26
(hope nobody has plans over the holidays) to be accepted for PHP 5.6,
assuming minimal two week discussion and one week voting periods.Nope, you can introduce RFCs until the first alpha, RFCs under discussion or
under voting are allowed to be added (until the first beta).Ofc. this still leaves with only a month, which also includes chirstmas/new
year so not that much time, but we are already a bit behind schedule.
Yup, with Christmas and all, that will slow things down.
We still can accept little delays, we all are humans, but not a one month delay.
We must release final on June
Julien
2013.12.12. 19:48, "Adam Harvey" aharvey@php.net ezt írta:
As you probably all remember the first beta usually means feature
freeze,
so no new additions are allowed, only fixes, so the code can stabilize
in
the beta and RC phase.
Learning from the past we would also like to introduce a new rule
about
not
accepting new RFCs targeting 5.6.0 after the first alpha is shipped,
because given the discussion and voting period it can force us into a
spot
where we have to chose betweenI like this: +1.
If it works well, then we probably want to announce the calendar a
little earlier for the 2015 release, since there's now a pretty narrow
window to propose an RFC and have it voted on before January 16. By my
estimation, an RFC will have to enter "in discussion" by December 26
(hope nobody has plans over the holidays) to be accepted for PHP 5.6,
assuming minimal two week discussion and one week voting periods.Nope, you can introduce RFCs until the first alpha, RFCs under
discussion or
under voting are allowed to be added (until the first beta).Ofc. this still leaves with only a month, which also includes
chirstmas/new
year so not that much time, but we are already a bit behind schedule.Yup, with Christmas and all, that will slow things down.
We still can accept little delays, we all are humans, but not a one month
delay.
We must release final on JuneJulien
Hi,
I plan to tag the the first alpha today, and release it tomorrow, so the
time for new RFCs are almost up.
I'm writing one up literally as we speak. Any chance of a hard
deadline on time to get it done by, or maybe pushing it back a day?
2013.12.12. 19:48, "Adam Harvey" aharvey@php.net ezt írta:
As you probably all remember the first beta usually means feature
freeze,
so no new additions are allowed, only fixes, so the code can stabilize
in
the beta and RC phase.
Learning from the past we would also like to introduce a new rule
about
not
accepting new RFCs targeting 5.6.0 after the first alpha is shipped,
because given the discussion and voting period it can force us into a
spot
where we have to chose betweenI like this: +1.
If it works well, then we probably want to announce the calendar a
little earlier for the 2015 release, since there's now a pretty narrow
window to propose an RFC and have it voted on before January 16. By my
estimation, an RFC will have to enter "in discussion" by December 26
(hope nobody has plans over the holidays) to be accepted for PHP 5.6,
assuming minimal two week discussion and one week voting periods.Nope, you can introduce RFCs until the first alpha, RFCs under
discussion or
under voting are allowed to be added (until the first beta).Ofc. this still leaves with only a month, which also includes
chirstmas/new
year so not that much time, but we are already a bit behind schedule.Yup, with Christmas and all, that will slow things down.
We still can accept little delays, we all are humans, but not a one month
delay.
We must release final on JuneJulien
Hi,
I plan to tag the the first alpha today, and release it tomorrow, so the
time for new RFCs are almost up.
On Wed, Jan 15, 2014 at 4:36 PM, Philip Sturgeon pjsturgeon@gmail.comwrote:
I'm writing one up literally as we speak. Any chance of a hard
deadline on time to get it done by, or maybe pushing it back a day?
I don't wanna be too strict about this, if you can put it up for discussion
this week (and make sure that it is implemented and voted before the first
beta) then it will make it.
We just don't want to handle a situation when everybody comes up with new
RFCs in the last minute before the feature freeze.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Wed, Jan 15, 2014 at 4:36 PM, Philip Sturgeon pjsturgeon@gmail.comwrote:
I'm writing one up literally as we speak. Any chance of a hard
deadline on time to get it done by, or maybe pushing it back a day?I don't wanna be too strict about this, if you can put it up for discussion
this week (and make sure that it is implemented and voted before the first
beta) then it will make it.
We just don't want to handle a situation when everybody comes up with new
RFCs in the last minute before the feature freeze.
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.
Several betas will then happen to fix last bugs in the implementations.
Thx,
Julien.Pauli
On Wed, Jan 15, 2014 at 4:36 PM, Philip Sturgeon pjsturgeon@gmail.comwrote:
I'm writing one up literally as we speak. Any chance of a hard
deadline on time to get it done by, or maybe pushing it back a day?
The hard deadline is Feb 21, which is 14 (discussion) + 7 (voting) + 2
(tagging) days before the beta 1 release. The point of the "no new RFCs
after alpha" rule is that people don't do something like this (submit RFCs
that fit into the last second before feature freeze). As long as you keep a
a reasonable time buffer (presumably something like two weeks, i.e. start
of February) and it's not some uber-serious RFC, I'm sure nobody has a
problem with you submitting it after alpha ;)
Nikita
On Wed, Jan 15, 2014 at 4:36 PM, Philip Sturgeon pjsturgeon@gmail.com
wrote:I'm writing one up literally as we speak. Any chance of a hard
deadline on time to get it done by, or maybe pushing it back a day?The hard deadline is Feb 21, which is 14 (discussion) + 7 (voting) + 2
(tagging) days before the beta 1 release. The point of the "no new RFCs
after alpha" rule is that people don't do something like this (submit RFCs
that fit into the last second before feature freeze). As long as you keep a
a reasonable time buffer (presumably something like two weeks, i.e. start
of February) and it's not some uber-serious RFC, I'm sure nobody has a
problem with you submitting it after alpha ;)Nikita
Great.
I'll have it up today anyway. First time jitters.
2013.12.12. 19:48, "Adam Harvey" aharvey@php.net ezt írta:
As you probably all remember the first beta usually means feature
freeze,
so no new additions are allowed, only fixes, so the code can
stabilize
in
the beta and RC phase.
Learning from the past we would also like to introduce a new rule
about
not
accepting new RFCs targeting 5.6.0 after the first alpha is shipped,
because given the discussion and voting period it can force us into a
spot
where we have to chose betweenI like this: +1.
If it works well, then we probably want to announce the calendar a
little earlier for the 2015 release, since there's now a pretty narrow
window to propose an RFC and have it voted on before January 16. By my
estimation, an RFC will have to enter "in discussion" by December 26
(hope nobody has plans over the holidays) to be accepted for PHP 5.6,
assuming minimal two week discussion and one week voting periods.Nope, you can introduce RFCs until the first alpha, RFCs under
discussion or
under voting are allowed to be added (until the first beta).Ofc. this still leaves with only a month, which also includes
chirstmas/new
year so not that much time, but we are already a bit behind schedule.Yup, with Christmas and all, that will slow things down.
We still can accept little delays, we all are humans, but not a one month
delay.
We must release final on JuneJulien
Hi,
I plan to tag the the first alpha today, and release it tomorrow, so the
time for new RFCs are almost up.
Hi,
I had to recreate my dev environment as my home desktop got some hardware
issues, and I didn't wanted to tag the release without a bit more testing.
Hopefully I can tag the release today, and I will talk with Julien and the
windows build guys about the next possible release date.
Sorry for the delay!
I had to recreate my dev environment as my home desktop got some hardware
issues, and I didn't wanted to tag the release without a bit more testing.
Hopefully I can tag the release today, and I will talk with Julien and the
windows build guys about the next possible release date.
Simply drop a mail to Steve (added to the loop) and me along with the
tag mail to the other RM, that will make it.
Thanks for your work!
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
I plan to tag the the first alpha today, and release it tomorrow, so the
time for new RFCs are almost up.I had to recreate my dev environment as my home desktop got some hardware
issues, and I didn't wanted to tag the release without a bit more testing.
Hopefully I can tag the release today, and I will talk with Julien and the
windows build guys about the next possible release date.Sorry for the delay!
I'm quite happy about the delay, as it's allowed me to use a Friday
evening productively hacking together a skeletal draft of the PHP 5.6
migration guide — it's not on the mirrors yet, but it is on
docs.php.net: http://docs.php.net/manual/en/migration56.php.
At this stage, 5.6 features aren't being documented outside of the
migration guide, since we're not at the feature freeze yet, so some of
the new features are only minimally documented. (For instance, there
are many variations of splat and variadic syntax that aren't covered
at present.) Once we hit feature freeze, they'll start getting proper
pages/sections in the language reference and will have more
comprehensive documentation (particularly if you help write it).
For developers who've committed significant code to 5.6, please make
sure your feature/deprecation/change is mentioned somewhere in there —
if it hasn't been, it's almost certainly because it wasn't in
UPGRADING, so please fix that. :) Please also feel free to jump in and
edit anything you're unhappy with! Some of the smaller changes were a
bit opaque.
Thanks,
Adam, who really doesn't want to spend the eventual 5.6.0 release day
the way he spent the 5.5.0 release day.
I plan to tag the the first alpha today, and release it tomorrow, so the
time for new RFCs are almost up.I had to recreate my dev environment as my home desktop got some hardware
issues, and I didn't wanted to tag the release without a bit more testing.
Hopefully I can tag the release today, and I will talk with Julien and the
windows build guys about the next possible release date.Sorry for the delay!
I'm quite happy about the delay, as it's allowed me to use a Friday
evening productively hacking together a skeletal draft of the PHP 5.6
migration guide — it's not on the mirrors yet, but it is on
docs.php.net: http://docs.php.net/manual/en/migration56.php.
What a nice idea, we are talking about doc and migration guide before
even the first alpha !
Nice nice :-)
At this stage, 5.6 features aren't being documented outside of the
migration guide, since we're not at the feature freeze yet, so some of
the new features are only minimally documented. (For instance, there
are many variations of splat and variadic syntax that aren't covered
at present.) Once we hit feature freeze, they'll start getting proper
pages/sections in the language reference and will have more
comprehensive documentation (particularly if you help write it).
Sounds like a nice plan.
For developers who've committed significant code to 5.6, please make
sure your feature/deprecation/change is mentioned somewhere in there —
if it hasn't been, it's almost certainly because it wasn't in
UPGRADING, so please fix that. :) Please also feel free to jump in and
edit anything you're unhappy with! Some of the smaller changes were a
bit opaque.
Thx for the reminder ! ;-)
Thanks,
Adam, who really doesn't want to spend the eventual 5.6.0 release day
the way he spent the 5.5.0 release day.
Lol, I don't remember that, ping me when you want to refresh my mind.
Always nice to learn from past experiences.
Julien.Pauli