7.0.0 release

Hi!

So in the end, a solution is wanted. I don't think any opinion is
allowed to be ignored for such a topic. So options

a) release on 26th including all known bug fixes
b) do RC8, assume there are no bugs, so target 10th for RTM
c) do RC8, release on 3rd, expect there are no bugs come in
d) continue issuing release candidates till it's stable enough (needs definition of stable and probably an RFC)

I would really ask to reach a consent on either a) or c). IMO, the
options b) and d) are the direct road to curbing 7.0.0. There is no
hurry to release just to release, but it is definitely harmful to slow
down the rise.

I like option c. The count bug looks like it could break a bunch of
apps, so releasing with it is possible but not ideal. Since we have a
fix for it I'd just wait another week. Not releasing on holiday is also
a plus in my book (not enough by itself to wait another week but in
conjunction with the actual serious bug in my opinion it tips the scale).
P.S. of course I also assume if somebody discovers huge bug before the
3rd we'd have to reconsider, but otherwise we should assume RC8 is the
future GA tag.

--
Stas Malyshev
smalyshev@gmail.com

Hi,

it is sad to see that the discussion went in the direction it went, but
I'm glad to have missed that being away all day and at the end of it
realizing my mail server messed up. Please lets get the tone down and
discuss factually!

I would like to turn back to the point I was depicting in my first mail

• the current stuff destined (including the bug fix for the sym table
  issue ofc) into the 7.NEXT looks pretty much like a set of fixes for a
  patch version. It is enough to go through the NEWS of 5.5 or 5.6 and
  compare to realize that. In aforementioned NEWS files, several bugs can
  be evaluated even as more critical as the subject caused the
  discussion. An accusation that the intention to deliver this as GA has
  the purpose of something bad has therefore just no objective base. In
  opposite - looking like a patch release is a testimony that 7.0 is ripe
  enough to enter the routine life cycle.

Today, we have a set of patches that can deliver a stable 7.0.0 to the
today's knowledge (remember also 5.x NEWS files in conjunction with
this). I probably just repeat what I was telling - any known app
compatible with 7.0.0 today has the tests green today.

To comply with the above and the definition of stable. Now, with
7.0.0. The gap between 5 and 7 is big, the number of
ported apps is small, same with the number of developers using it. How
do we get the wheel to spin? Please think strategically. How do we get
the 7.0.0 GA to have the gap to be the same as between some adjacent
PHP5 minor releases?

Short - one can delay. There is a group of people who wants it to be
done. What does that mean? That means, less usage, less testing, slower
bug discovery. Even shorter - one can release. What does that mean?
That means that we are on the track, more apps are getting ported, more
people use it, more bugs we fix - we are stable.

Just to remind - the RC7 was caused but the exact reason that it were
impossible and extremely bad to deliver an untested lot of various and
partially bad issues. And that was suitable. That's why also other two
weeks was taken. It is quite pointless to have a one week RC, because
the feedback on that is negligible and consequently no real bugs are
catched. It doesn't comply with the expressed intention to validate the
bug fix. Now, it is of course the matter of the definition, but issuing
one more RC for the bugs that are don't even stand near the cause of
the RC7 doesn't sound like an appropriate action. Either the bugs are
heavy weight and the fixes need to be properly tested, or they are
not. Except one turns back to the thesis that there should be no bugs.

So in the end, a solution is wanted. I don't think any opinion is
allowed to be ignored for such a topic. So options

a) release on 26th including all known bug fixes
b) do RC8, assume there are no bugs, so target 10th for RTM
c) do RC8, release on 3rd, expect there are no bugs come in
d) continue issuing release candidates till it's stable enough (needs
definition of stable and probably an RFC)

I would really ask to reach a consent on either a) or c). IMO, the
options b) and d) are the direct road to curbing 7.0.0. There is no
hurry to release just to release, but it is definitely harmful to slow
down the ris...

I think a is best but c works too, although it makes no sense really...

cheers,
Derick, Nikita

Hi,

it is sad to see that the discussion went in the direction it went, but I'm glad to have missed that being away all day and at the end of it realizing my mail server messed up. Please lets get the tone down and discuss factually!

I would like to turn back to the point I was depicting in my first mail - the current stuff destined (including the bug fix for the sym table issue ofc) into the 7.NEXT looks pretty much like a set of fixes for a patch version. It is enough to go through the NEWS of 5.5 or 5.6 and compare to realize that. In aforementioned NEWS files, several bugs can be evaluated even as more critical as the subject caused the discussion. An accusation that the intention to deliver this as GA has the purpose of something bad has therefore just no objective base. In opposite - looking like a patch release is a testimony that 7.0 is ripe enough to enter the routine life cycle.

Today, we have a set of patches that can deliver a stable 7.0.0 to the today's knowledge (remember also 5.x NEWS files in conjunction with this). I probably just repeat what I was telling - any known app compatible with 7.0.0 today has the tests green today.

To comply with the above and the definition of stable. Now, with
7.0.0. The gap between 5 and 7 is big, the number of
ported apps is small, same with the number of developers using it. How
do we get the wheel to spin? Please think strategically. How do we get the 7.0.0 GA to have the gap to be the same as between some adjacent PHP5 minor releases?

Short - one can delay. There is a group of people who wants it to be done. What does that mean? That means, less usage, less testing, slower bug discovery. Even shorter - one can release. What does that mean? That means that we are on the track, more apps are getting ported, more people use it, more bugs we fix - we are stable.

Just to remind - the RC7 was caused but the exact reason that it were impossible and extremely bad to deliver an untested lot of various and partially bad issues. And that was suitable. That's why also other two weeks was taken. It is quite pointless to have a one week RC, because the feedback on that is negligible and consequently no real bugs are catched. It doesn't comply with the expressed intention to validate the bug fix. Now, it is of course the matter of the definition, but issuing one more RC for the bugs that are don't even stand near the cause of the RC7 doesn't sound like an appropriate action. Either the bugs are heavy weight and the fixes need to be properly tested, or they are not. Except one turns back to the thesis that there should be no bugs.

So in the end, a solution is wanted. I don't think any opinion is allowed to be ignored for such a topic. So options

a) release on 26th including all known bug fixes
b) do RC8, assume there are no bugs, so target 10th for RTM
c) do RC8, release on 3rd, expect there are no bugs come in
d) continue issuing release candidates till it's stable enough (needs definition of stable and probably an RFC)

I would really ask to reach a consent on either a) or c). IMO, the options b) and d) are the direct road to curbing 7.0.0. There is no hurry to release just to release, but it is definitely harmful to slow down the rise.

Thanks

Anatol

when is it available from Windows binaries download site? It still says
this:

7 has no release http://s13.postimg.org/t6j2b0czb/2015_11_23_2241.png

http://windows.php.net/download/

So in the end, a solution is wanted. I don't think any opinion is allowed to be ignored for such a topic. So options

a) release on 26th including all known bug fixes
b) do RC8, assume there are no bugs, so target 10th for RTM
c) do RC8, release on 3rd, expect there are no bugs come in
d) continue issuing release candidates till it's stable enough (needs definition of stable and probably an RFC)

I would really ask to reach a consent on either a) or c). IMO, the options b) and d) are the direct road to curbing 7.0.0. There is no hurry to release just to release, but it is definitely harmful to slow down the rise.

My vote (if it matters) goes for c)

It also has the nice side effect of not clashing with ~Black Friday, and by next week, the "oh wow Wordpress just moved to Node.js" hype will have died down too, giving PHP 7 more of the attention it deserves ;)

c) do RC8, release on 3rd, expect there are no bugs come in

+1

a) release on 26th including all known bug fixes
b) do RC8, assume there are no bugs, so target 10th for RTM
c) do RC8, release on 3rd, expect there are no bugs come in
d) continue issuing release candidates till it's stable enough (needs
definition of stable and probably an RFC)

C would be ideal.
Give everyone a chance to validate the count fix, plus its a nice date that
does not leave Americans
up in arms about turkeys and its way before christmas, very neutral ground

--
Rafael Dohms
PHP Evangelist and Community Leader
http://doh.ms
http://www.amsterdamphp.nl <http://wwwamsterdamphp.nl

a) release on 26th including all known bug fixes
b) do RC8, assume there are no bugs, so target 10th for RTM
c) do RC8, release on 3rd, expect there are no bugs come in
d) continue issuing release candidates till it's stable enough (needs
definition of stable and probably an RFC)

I would really ask to reach a consent on either a) or c). IMO, the options
b) and d) are the direct road to curbing 7.0.0. There is no hurry to
release just to release, but it is definitely harmful to slow down the rise.

Thanks

Anatol

I prefer a over c.

As you said, we can deliver a stable and high quality 7.0.0 today. An RC
period where you expect no bugs does not sound productive to me.

We all know the "real testing" doesn't begin until it's released, and the
best way to find what is left (things we have not found in over a year of
development and testing), is to get more people looking at it.

Delaying the release is actually delaying the discovery of bugs that affect
real world applications that we do not have access to, and cannot test
with. Many teams will not even start testing with 7 until it gets an
official release.

If something is found, it doesn't make the release any less high quality.
Any bugs that would be found between now and the 3rd will still be found
(and probably more), and they will still be fixed. The only difference
would be a 0.0.1 version number.

/2c

a) release on 26th including all known bug fixes
b) do RC8, assume there are no bugs, so target 10th for RTM
c) do RC8, release on 3rd, expect there are no bugs come in
d) continue issuing release candidates till it's stable enough (needs
definition of stable and probably an RFC)

I would really ask to reach a consent on either a) or c). IMO, the options
b) and d) are the direct road to curbing 7.0.0. There is no hurry to
release just to release, but it is definitely harmful to slow down the rise.

The little poll I sent yesterday in response to Phil's email has an even
split.

Question: Create an RC for this count($array) fix?
Responses: 26 for, 26 against
http://poll.pollcode.com/92997454_result?v

Maybe all it says is the community is split, and we won't reach consensus.

So while I'm +1 on (c), I defer to the wisdom and guidance of our RMs. :)