After some Twitter hints that I should get my act together and finally move
this to a vote, it’s finally happening:
https://wiki.php.net/rfc/php7timeline#vote
Cast your vote!
Zeev
After some Twitter hints that I should get my act together and finally move
this to a vote, it’s finally happening:https://wiki.php.net/rfc/php7timeline#vote
Cast your vote!
Zeev
Morning Zeev,
Proposed milestones column needs to change from mid October to
November.
Cheers
Joe
After some Twitter hints that I should get my act together and finally
move
this to a vote, it’s finally happening:https://wiki.php.net/rfc/php7timeline#vote
Cast your vote!
Zeev
Morning Zeev,
Proposed milestones column needs to change from mid October toNovember.
Cheers
Joe--
Looks good, except I think you should remove the language expressing
opinion about the general merits of backwards compatibility, as that falls
outside the scope of the timeline being voted on. Plus it's an issue that
really should be discussed and, if needed, voted on separately, not as a
single sentence stuffed into an RFC about a release timeline. If I were to
vote yes on this timeline, I would not want my vote interpreted as an
endorsement of that position on BC. I think it's overreach and scope creep
that should be removed.
Other than that one serious (but easily fixable) flaw, I think it's great!
--Kris
Specifically, this is the sentence that just seems completely out of place:
"Arguably, while we should definitely take the opportunity to implement
compatibility-breaking changes in 7.0, we also shouldn't turn it into a
compatibility-breaking festival, as the more we break, the more likely it
is users would delay upgrades, stay with old, insecure versions - or even
consider other alternative options."
Mind you, I don't necessarily disagree with this opinion, but I don't think
it belongs in this RFC as people's votes to approve the timeline could
later be construed as endorsements of the BC philosophy you expressed, as
well. That bothers me, probably enough to make me vote against this, so I
really hope you remove it. I'd certainly have no objection to seeing that
expanded into its own RFC, though. =)
--Kris
On Fri, Nov 21, 2014 at 12:18 AM, Joe Watkins pthreads@pthreads.org
wrote:After some Twitter hints that I should get my act together and finally
move
this to a vote, it’s finally happening:https://wiki.php.net/rfc/php7timeline#vote
Cast your vote!
Zeev
Morning Zeev,
Proposed milestones column needs to change from mid October toNovember.
Cheers
Joe--
Looks good, except I think you should remove the language expressing
opinion about the general merits of backwards compatibility, as that falls
outside the scope of the timeline being voted on. Plus it's an issue that
really should be discussed and, if needed, voted on separately, not as a
single sentence stuffed into an RFC about a release timeline. If I were to
vote yes on this timeline, I would not want my vote interpreted as an
endorsement of that position on BC. I think it's overreach and scope creep
that should be removed.Other than that one serious (but easily fixable) flaw, I think it's great!
--Kris
Kris,
This existed in the RFC since the get go and I don't believe anybody raised any concerns about it. There was plenty of time for discussion. Either way approval of this RFC won't have any effect on the approval or rejection of other RFCs.
Kris, All - I'm now on a 7th day straight of a paralyzing 39.5C temperature. Let's focus on what matters. I at least don't have energy to respond to the rest.
Zeev
Specifically, this is the sentence that just seems completely out of place:
"Arguably, while we should definitely take the opportunity to implement compatibility-breaking changes in 7.0, we also shouldn't turn it into a compatibility-breaking festival, as the more we break, the more likely it is users would delay upgrades, stay with old, insecure versions - or even consider other alternative options."
Mind you, I don't necessarily disagree with this opinion, but I don't think it belongs in this RFC as people's votes to approve the timeline could later be construed as endorsements of the BC philosophy you expressed, as well. That bothers me, probably enough to make me vote against this, so I really hope you remove it. I'd certainly have no objection to seeing that expanded into its own RFC, though. =)
--Kris
After some Twitter hints that I should get my act together and finally move
this to a vote, it’s finally happening:https://wiki.php.net/rfc/php7timeline#vote
Cast your vote!
Zeev
Morning Zeev,
Proposed milestones column needs to change from mid October toNovember.
Cheers
Joe--
Looks good, except I think you should remove the language expressing opinion about the general merits of backwards compatibility, as that falls outside the scope of the timeline being voted on. Plus it's an issue that really should be discussed and, if needed, voted on separately, not as a single sentence stuffed into an RFC about a release timeline. If I were to vote yes on this timeline, I would not want my vote interpreted as an endorsement of that position on BC. I think it's overreach and scope creep that should be removed.
Other than that one serious (but easily fixable) flaw, I think it's great!
--Kris
Kris,
This existed in the RFC since the get go and I don't believe anybody
raised any concerns about it. There was plenty of time for discussion.
Either way approval of this RFC won't have any effect on the approval or
rejection of other RFCs.
I have to agree with the concerns raised by Levi and Pierre regarding this
matter. Regardless of the reasons, too much time has passed since those
discussions for them to really be relevant today, and it does feel a bit
sudden to have this suddenly pop-out for a vote after all this time and
without any warning.
As far as the issue I raised is concerned, didn't I raise that same concern
during the last discussion? I could be mistaken, but now that you mention
it, I don't think this is the first time I've raised concerns about that.
Besides, the whole "I can't focus on that because it's not important"
argument just doesn't make any sense to me. It adds nothing to the RFC and
would literally take like 5 seconds to remove; probably about the same time
it took for you to explain in that email why it wasn't worth removing. In
any case, I am definitely raising concern about it now and I'm not aware of
any rule saying that's not permitted. If you like, I'll even fix it for
you with your permission (since it's literally just removing a single
sentence) so you don't have to waste any time/energy dealing with it.
Kris, All - I'm now on a 7th day straight of a paralyzing 39.5C
temperature. Let's focus on what matters. I at least don't have energy to
respond to the rest.
Holy shit that sucks! I can certainly understand your lack of patience in
dealing with issues surrounding this RFC. Unfortunately, they are
important-- at least, they're important to the people who are raising
them. It may be prudent for you to find someone you trust to help you
address them given your situation. Either way, this abrupt vote after such
a long pause does concern me, as does the apparent lack of willingness to
discuss concerns with it. These are just my opinions, of course, but for
whatever it's worth, I have some serious concerns about this.
--Kris
After some Twitter hints that I should get my act together and finally move
this to a vote, it’s finally happening:https://wiki.php.net/rfc/php7timeline#vote
Cast your vote!
Zeev
Hi,
could you update the timeline to mention when do you want to start the
alpha and beta cycle?
for 5.6 the start of the alpha cycle indicated that we don't accept new
proposals, and the start of the beta cycle indicated that we won't accept
new features even if the RFC was already proposed or even accepted (but the
patch wasn't finished or merged in time).
you do mention the RC cycle as point 3, and my guess is that point 2, could
be the beta cycle because your definition ("Finalize implementation &
testing of new features") matches what we do with betas, but if that
assumption is correct, then your RFC is missing a target date for the start
of the alpha cycle, and that is important to know if we want to keep the
rule that there could be no new RFCs targetting PHP7 after that date.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
After some Twitter hints that I should get my act together and finally move
this to a vote, it’s finally happening:https://wiki.php.net/rfc/php7timeline#vote
Cast your vote!
Zeev
Hi,
could you update the timeline to mention when do you want to start the alpha and beta cycle?
for 5.6 the start of the alpha cycle indicated that we don't accept new proposals, and the start of the beta cycle indicated that we won't accept new features even if the RFC was already proposed or even accepted (but the patch wasn't finished or merged in time).
you do mention the RC cycle as point 3, and my guess is that point 2, could be the beta cycle because your definition ("Finalize implementation & testing of new features") matches what we do with betas, but if that assumption is correct, then your RFC is missing a target date for the start of the alpha cycle, and that is important to know if we want to keep the rule that there could be no new RFCs targetting PHP7 after that date.
I think the "finalize implementation" stage corresponds to our alpha stage, as we're not feature complete.
The proposal does suggest to go directly to an RC cycle afterwards, but it could read beta / RC too. The difference between betas and RCs is typically very small, they're both feature complete and only imply different levels of quality. Personally I don't think we need both.
Zeev
After some Twitter hints that I should get my act together and finally
move
this to a vote, it’s finally happening:https://wiki.php.net/rfc/php7timeline#vote
Cast your vote!
Zeev
Hi,
could you update the timeline to mention when do you want to start the
alpha and beta cycle?for 5.6 the start of the alpha cycle indicated that we don't accept new
proposals, and the start of the beta cycle indicated that we won't accept
new features even if the RFC was already proposed or even accepted (but the
patch wasn't finished or merged in time).
you do mention the RC cycle as point 3, and my guess is that point 2,
could be the beta cycle because your definition ("Finalize implementation &
testing of new features") matches what we do with betas, but if that
assumption is correct, then your RFC is missing a target date for the start
of the alpha cycle, and that is important to know if we want to keep the
rule that there could be no new RFCs targetting PHP7 after that date.I think the "finalize implementation" stage corresponds to our alpha
stage, as we're not feature complete.
ok
The proposal does suggest to go directly to an RC cycle afterwards, but it
could read beta / RC too. The difference between betas and RCs is
typically very small, they're both feature complete and only imply
different levels of quality. Personally I don't think we need both.
In this case the 3 month period will be too short imo.
We release RCs/betas every two weeks, so 3 months would be about 6 release.
5.6.0 had 3 alpha, 4 beta and 4 rc before release.
5.5.0 had 6 alpha, 4 beta and 3 rc before release.
5.4.0 had 3 alpha, 2 beta and 8 rc before release.
5.3.0 had 3 alpha, 1 beta and 4 rc before release
5.2.0 had 6 rc before release.
5.1.0 had 6 rc before release.
based on that I would say that our average beta+rc release number is around
7, and sometimes the release for a beta/RC can be delayed, so I think that
having only 3 months for the beta+RC period is too optimistic, we should
make that into 4 months at least, we could either push out the ETA for GA
or move back the alpha period by a month.
sorry if this seems to be nitpicking, just trying to put my experiences
into use.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
In this case the 3 month period will be too short imo.
We release RCs/betas every two weeks, so 3 months would be about 6 release.
5.6.0 had 3 alpha, 4 beta and 4 rc before release.
5.5.0 had 6 alpha, 4 beta and 3 rc before release.
5.4.0 had 3 alpha, 2 beta and 8 rc before release.
5.3.0 had 3 alpha, 1 beta and 4 rc before release
5.2.0 had 6 rc before release.
5.1.0 had 6 rc before release.based on that I would say that our average beta+rc release number is around
7, and sometimes the release for a beta/RC can be delayed, so I think that
having only 3 months for the beta+RC period is too optimistic, we should
make that into 4 months at least, we could either push out the ETA for GA
or move back the alpha period by a month.
Agreed. This is the key reason why our "annual" release cycle has been
"15 monthly" in practice — we've consistently underestimated the
number of beta and RC releases required for a .0 stable.
Adam
Ferenc, all,
The RFC has provisions for making the 3rd and 4th milestones move as needed:
“It's worth noting that the 3rd and 4th milestones will be quality
dependent. If we have evidence that suggests that PHP 7 isn't sufficiently
mature to go into the RC stage in June, or GA in October - we should of
course adjust the timeline accordingly, and not push out a half-baked
release. However, the goal would be to stick as much as possible to the
deadline of new going-into-7.0 RFCs, and strive to follow the timelines for
the 2nd and 3rd milestones as much as possible, to ensure an October 2015
release of PHP 7.0.”
This language attempts to balance the motivation to get PHP 7.0 out to
market as soon as possible, with the unwillingness to compromise on
quality. If we end up having to have 4 months of betas/RCs instead of 3 –
then we will…
Zeev
based on that I would say that our average beta+rc release number is around
7, and sometimes the release for a beta/RC can be delayed, so I think that
having only 3 months for the beta+RC period is too optimistic, we should
make that into 4 months at least, we could either push out the ETA for GA
or move back the alpha period by a month.
sorry if this seems to be nitpicking, just trying to put my experiences
into use.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Ferenc, all,
The RFC has provisions for making the 3rd and 4th milestones move as needed:
“It's worth noting that the 3rd and 4th milestones will be quality
dependent. If we have evidence that suggests that PHP 7 isn't sufficiently
mature to go into the RC stage in June, or GA in October - we should of
course adjust the timeline accordingly, and not push out a half-baked
release. However, the goal would be to stick as much as possible to the
deadline of new going-into-7.0 RFCs, and strive to follow the timelines for
the 2nd and 3rd milestones as much as possible, to ensure an October 2015
release of PHP 7.0.”This language attempts to balance the motivation to get PHP 7.0 out to
market as soon as possible, with the unwillingness to compromise on
quality. If we end up having to have 4 months of betas/RCs instead of 3 –
then we will…Zeev
based on that I would say that our average beta+rc release number is around
7, and sometimes the release for a beta/RC can be delayed, so I think that
having only 3 months for the beta+RC period is too optimistic, we should
make that into 4 months at least, we could either push out the ETA for GA
or move back the alpha period by a month.sorry if this seems to be nitpicking, just trying to put my experiences
into use.
Which is very valuable and pretty matches our experiences for all
releases since 5.3 but 5.4.0 (only in time).
That's why I strongly suggest to make a more realistic time plan and
stick to it. Specific dates can or should be define later but the
period (mid october f.e.) should be defined now. One week more when it
is about fixing one last critical bug for an existing feature is
perfectly OK, 1 month to actually finish a new feature may not be
good, at all.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
That's why I strongly suggest to make a more realistic time plan and
stick to it. Specific dates can or should be define later but the
period (mid october f.e.) should be defined now. One week more when it
is about fixing one last critical bug for an existing feature is
perfectly OK, 1 month to actually finish a new feature may not be
good, at all.
When a customer tells me I have to give him a completion date I have a
stock answer. 'When you sign off on the specification'. The current
problem is that we have no idea just what form PHP7 is going to take,
and no idea just how much code will need to be reworked as a result.
There is a lot of parallel developments going on all with different
goals and in my book all at odds with a cohesive roadmap? Many people
want their pet features included ASAP but as yet there is no agreement
even on what PHP7 will be? Until there are a set of goals any planning
on time is irrelevant.
It IS all chicken and egg since one can't know now just how long it will
take to do some of the things being discussed, and it may be that it's
impossible to achieve a preferred goal in a reasonable time frame? THAT
is basically what happened with PHP6? The selections made for the goal
turned out to be the wrong ones but it took time for people to give in
ad scrap that roadmap.
From a user point of view I'd rather know what will NOT be part of PHP7
early, and anything being removed will be tagged as deprecated in PHP5.7
... I don't see any way forward without a bridging build to help
identify code that needs work, and I would like to make a case for NOT
loading PHP7 down with compatibility switches like e_strict! Lets keep
the compatibility aspect to PHP5.7 and those of us who don't have time
to 'upgrade' will continue to run PHP5 for another 10+ years. PHP7
should be - hopefully - a single clean interface with in my book UTF8
capability as a bare minimum. But I don't think we need Python3 type
breaks to achieve this since much of the core has already had UTF8
sneaked in via the back door. I'm thinking more like a C -> C++ break
where the core procedural framework still works, but people can add OO
namespaces on top which do not have to be 'required'. I just don't see
how the 'everything must be exceptions' camp can be accommodated with
procedural error handling?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
That's why I strongly suggest to make a more realistic time plan and
stick to it. Specific dates can or should be define later but the
period (mid october f.e.) should be defined now. One week more when it
is about fixing one last critical bug for an existing feature is
perfectly OK, 1 month to actually finish a new feature may not be
good, at all.When a customer tells me I have to give him a completion date I have a
stock answer. 'When you sign off on the specification'. The current
problem is that we have no idea just what form PHP7 is going to take,
and no idea just how much code will need to be reworked as a result.There is a lot of parallel developments going on all with different
goals and in my book all at odds with a cohesive roadmap? Many people
want their pet features included ASAP but as yet there is no agreement
even on what PHP7 will be? Until there are a set of goals any planning
on time is irrelevant.It IS all chicken and egg since one can't know now just how long it will
take to do some of the things being discussed, and it may be that it's
impossible to achieve a preferred goal in a reasonable time frame? THAT
is basically what happened with PHP6? The selections made for the goal
turned out to be the wrong ones but it took time for people to give in
ad scrap that roadmap.From a user point of view I'd rather know what will NOT be part of PHP7
early, and anything being removed will be tagged as deprecated in PHP5.7
... I don't see any way forward without a bridging build to help
identify code that needs work, and I would like to make a case for NOT
loading PHP7 down with compatibility switches like e_strict! Lets keep
the compatibility aspect to PHP5.7 and those of us who don't have time
to 'upgrade' will continue to run PHP5 for another 10+ years. PHP7
should be - hopefully - a single clean interface with in my book UTF8
capability as a bare minimum. But I don't think we need Python3 type
breaks to achieve this since much of the core has already had UTF8
sneaked in via the back door. I'm thinking more like a C -> C++ break
where the core procedural framework still works, but people can add OO
namespaces on top which do not have to be 'required'. I just don't see
how the 'everything must be exceptions' camp can be accommodated with
procedural error handling?--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk--
A valid point. Perhaps, before we decide on a timeline for release, we
should first decide on a timeline for acceptance of new features/etc. We
should have a cut-off date for RFCs targetted for PHP 7. After that date
has passed, we gather up all the stuff slated for 7.0 and figure out how
long it will take. That will yield the timeline we're looking for. Voting
on a release timeline before then just invites problems and confusion down
the line and would probably force us to ultimately come up with a revised
timeline later on, anyway. It would be better to do this by the book and
establish a scope cut-off before drafting any timeline for release.
Based on this, as well as flaws in the RFC itself, I'm going to have to
vote no. Not because I don't support a PHP 7 release timeline, but because
I don't think this RFC at this time is a responsible way to go about doing
it.
--Kris
After some Twitter hints that I should get my act together and finally move
this to a vote, it’s finally happening:https://wiki.php.net/rfc/php7timeline#vote
Cast your vote!
Zeev
Hi,
could you update the timeline to mention when do you want to start the alpha and beta cycle?
for 5.6 the start of the alpha cycle indicated that we don't accept new proposals, and the start of the beta cycle indicated that we won't accept new features even if the RFC was already proposed or even accepted (but the patch wasn't finished or merged in time).
you do mention the RC cycle as point 3, and my guess is that point 2, could be the beta cycle because your definition ("Finalize implementation & testing of new features") matches what we do with betas, but if that assumption is correct, then your RFC is missing a target date for the start of the alpha cycle, and that is important to know if we want to keep the rule that there could be no new RFCs targetting PHP7 after that date.I think the "finalize implementation" stage corresponds to our alpha stage, as we're not feature complete.
The proposal does suggest to go directly to an RC cycle afterwards, but it could read beta / RC too. The difference between betas and RCs is typically very small, they're both feature complete and only imply different levels of quality. Personally I don't think we need both.
This is not the case. Beta means beta status but may be not features
complete (as patch may have not made it yet). RCs on the other hand
are. RC means no more addition and focus only on fixing things.
This RFC is incomplete and unrealistic, besides not taking into
account other opinions. It should go back to discussions and solve the
obvious issues before even thinking about voting on it.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
After some Twitter hints that I should get my act together and finally move
this to a vote, it’s finally happening:
Given how long it has been since there was any activity on this topic,
I wish that you had issued a pre-vote email to the list to solicit
more feedback. Oh well.
I think working towards an October/November 2015 release is good; I
just want to clarify one thing:
The timeline for "Line up any remaining RFCs that target PHP 7.0."
ends on March 15, 2015. This implies that feature freeze will happen
on that date, correct?
This is an important thing to recognize if I am correct, as it is only
four months away.
-----Original Message-----
From: morrison.levi@gmail.com [mailto:morrison.levi@gmail.com] On
Behalf Of Levi Morrison
Sent: Friday, November 21, 2014 6:48 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] [VOTE] [RFC] PHP 7.0 timelineThe timeline for "Line up any remaining RFCs that target PHP 7.0."
ends on March 15, 2015. This implies that feature freeze will happen on
that
date, correct?
This is 'feature definition freeze'. It's not the standard 'feature freeze'
as it's defined in the industry, which means we're done developing the
features.
Zeev